--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-08
06:52 ---
Subject: Bug 23760
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-08 06:52:04
Modified files:
gcc/testsuite : ChangeLog
gcc/testsuite/gfor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-08
05:52 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From csm at gnu dot org 2005-09-08 05:49 ---
Confirmed. The doFinal methods should leave 'state' as-is, as the reporter
suggests. It is up to CipherSpi
subclasses to reset themselves when their 'engineDoFinal' methods are called.
--
What|Removed
--
What|Removed |Added
CC||fang at csl dot cornell dot
||edu
http://gcc.gnu.org/bugzilla/s
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org |dot au
Status|UNCONFIRME
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-08
03:07 ---
I think this is a good idea. I don't think we need a switch; this should just
be the default. We also need a documentation update to mention this. And, I
think the default ICE_EXIT_CODE shold be "2", unl
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-08 02:42
---
A more severe example is gdb.base/call-ar-st.c wherein the local static variable
"double_array" is not put to the debug info at all. Not even its name as in the
example here.
--
http://gcc.gnu.org/bugzilla/
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-08 02:35
---
>From the log, this was a gdb bug.
--
What|Removed |Added
Status|UNCONFIRMED
On a i686 platform, the example below is miscompiled with -O1.
I expect this program to print -0.96. Here's what it actually does:
$ g++ -O1 -o y y.cc
$ ./y
-1.288766
$ g++ -o y y.cc
$ ./y
-0.96
$
The value that the optimized version prints is actually different
on each run of the program
--- Additional Comments From normbograham at yahoo dot com 2005-09-08
01:43 ---
Ed:
I also have the same problem, but a little thought gives you a good work-
around. First a little background. There is a function that calls main.
This is the last function on the stack you can quer
--
What|Removed |Added
Known to fail||4.0.2 4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23774
The following compiled with -m32 -O2 -S
void badFunc (int size)
{
char temp[size];
temp[size-1] = '\0';
};
gives
badFunc:
mflr 0
stwu 1,-16(1)
stw 0,20(1)
addi 0,3,30
lwz 9,0(1)
mr 11,1
stw 31,12(1)
mr 31,1
rlwinm 0,0,0
In particular, describe in the detail all the allowed and disallowed changes to
the library headers (vs library proper, .so and .a): see the audit trail of
libstdc++/23767 for some examples.
--
Summary: Improve abi.html
Product: gcc
Version: 4.1.0
Stat
--
What|Removed |Added
Summary|[3.3/3.4 regression] [arm] |[3.4 regression] [arm] ICE
|ICE in change_address_1, at |in change_address_1, at
--- Additional Comments From raj dot khem at gmail dot com 2005-09-07
23:15 ---
I think it needs backporting this particular patch from Richard to 3.4 branch
submitted for bug #12133
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-07-09 10:06:03
There is an internal error in gcc when following code is compiled with -O2 -c
options.
=
typedef float floatvect2 __attribute__((mode(V2DF)));
typedef union
{
floatvect2 vector;
double f[2];
}resfloatvect2;
void tempf(double *x, double *y)
{
floatvect2 temp
--- Additional Comments From danglin at gcc dot gnu dot org 2005-09-07
22:45 ---
No longer occurs.
--
What|Removed |Added
Status|UNCONFIRMED |RES
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-09-07 22:43 ---
Subject: Re: __gnat_is_absolute_path: Segmentation fault
> Do you still see the problem ?
This is fixed.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22285
--- Additional Comments From bangerth at dealii dot org 2005-09-07 22:40
---
Yea, but I guess I'll leave this to you guys, that sounds too complicated
for me. I'll just stick my head out every once in a while and try to find
a loophope in your reasoning and to invent ways to show that
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-07 22:05 ---
It seems that expand generates different insns in 4.0 and 4.1 for the comparison
in question:
4.0 generates: (from .00.expand)
(insn 15 13 16 1 (set (reg/f:SI 62)
(mem/s/f:SI (plus:SI (re
--- Additional Comments From pcarlini at suse dot de 2005-09-07 21:36
---
(In reply to comment #16)
> I guess then there is no danger involved.
Yeah! ;)
> BTW, I'm not one of the corporate folks, so I have few problems with
> breaking ABI compatibility :-) I was just too fast raising
--
Bug 23261 depends on bug 23262, which changed state.
Bug 23262 Summary: [mingw32] rewind truncates file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23262
What|Old Value |New Value
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-07
21:33 ---
Patch commited, bug fixed.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
21:32 ---
Subject: Bug 23262
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 21:31:57
Modified files:
libgfortran: Change
--- Additional Comments From bangerth at dealii dot org 2005-09-07 21:27
---
I guess then there is no danger involved.
BTW, I'm not one of the corporate folks, so I have few problems with
breaking ABI compatibility :-) I was just too fast raising a point that
in the end didn't turn
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
21:25 ---
Subject: Bug 23262
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-07 21:25:40
Modified files:
libgfortran: ChangeLog acinclude.m4 config.h.in co
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-09-07
21:20 ---
Fixed on mainline and 4.0.
--
What|Removed |Added
Status|NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
21:19 ---
Subject: Bug 20848
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 21:19:21
Modified files:
gcc/fortran: Change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
21:11 ---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
21:08 ---
Subject: Bug 20848
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-07 21:08:24
Modified files:
gcc/fortran: ChangeLog symbol.c
gcc/tests
--- Additional Comments From chris at bubblescope dot net 2005-09-07 21:07
---
Actually for inline functions, even with -fno-implicit-templates,
instansiations are still generated (I can
kind of see why. You could argue they shouldn't be, but they are)
--
http://gcc.gnu.org/bugzill
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-07 21:07
---
The code in mem*.[ch] is much messier than I originally thought. There are
lots of casts in assignments of pointer variables. The macros in mem00.h
starting with Unit_Size, which are used in both lvalues and
--- Additional Comments From pcarlini at suse dot de 2005-09-07 21:04
---
(In reply to comment #12)
> What I had meant was liba.so containing an explicit specialization of
> std::vector and libb.so using it while being compiled with
> -fno-implicit-instantiations (or whatever the cor
--- Additional Comments From pcarlini at suse dot de 2005-09-07 20:58
---
(In reply to comment #11)
> I just tried adding a template parameter,
You mean, to the __normal_iterator class itself? That does not work, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-09-07
20:58 ---
Even with the committed patch, there is still something wrong
on i686:
$ cat compl.f
program main
complex (kind=10) a, b
integer(kind=1), dimension(32) :: ea, eb
equivalence (ea, a)
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:55
---
What I had meant was liba.so containing an explicit specialization of
std::vector and libb.so using it while being compiled with
-fno-implicit-instantiations (or whatever the correct name for that
flag was)
--- Additional Comments From chris at bubblescope dot net 2005-09-07 20:51
---
I just tried adding a template parameter, and it does break things unfortunatly.
In an "old" file define something like:
void f(vector::iterator v) {..}
and then try to call it from a file that includes the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
20:48 ---
Works just fine on the mainline.
--
What|Removed |Added
Known to work|3.3.2 3.4.4
--- Additional Comments From pcarlini at suse dot de 2005-09-07 20:45
---
(In reply to comment #9)
> Actually, __normal_iterator is what std::string uses for it's iterator class,
> so we could be in trouble.
As long as no user code expects instantiations of members of __normal_iterator
--- Additional Comments From chris at bubblescope dot net 2005-09-07 20:39
---
Actually, __normal_iterator is what std::string uses for it's iterator class, so
we could be in trouble.
On the note of removing enable_if, my only other thought is something like:
template
then change th
--- Additional Comments From pcarlini at suse dot de 2005-09-07 20:26
---
(In reply to comment #7)
> If you add a third argument to the constructor, don't you somehow have to
> add the old constructor with its two-argument signature to the library to
> allow old programs to link agains
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
20:21 ---
Subject: Bug 23419
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 20:21:34
Modified files:
libgfortran: Change
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:19
---
If you add a third argument to the constructor, don't you somehow have to
add the old constructor with its two-argument signature to the library to
allow old programs to link against the new library?
How wo
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
20:16 ---
Subject: Bug 23419
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-07 20:16:47
Modified files:
libgfortran: ChangeLog
libgfortran/io : w
--- Additional Comments From pcarlini at suse dot de 2005-09-07 20:14
---
(In reply to comment #5)
> How about something like:
Yes, in my mind earlier today I considered that solution. In principle should
work. However, there are issues, I'm afraid: optimization issues with the
extra du
--
What|Removed |Added
CC||bangerth at dealii dot org
Last reconfirmed|2005-09-06 18:49:14 |2005-09-07 20:12:20
d
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
20:08 ---
Note unlike PR 23691, this one does ___not___ work on the mainline. They might
be the same issue but
we won't really know until either one is fixed.
--
What|Removed |A
--- Additional Comments From chris at bubblescope dot net 2005-09-07 20:06
---
You are right, I previously didn't think it was possible without adding some
more template parameters.
However, I should have known there is nothing you can't do with a few templates
:)
How about something
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
20:06 ---
(In reply to comment #11)
> This is actually a duplicate of PR 23771. It compiles fine with 4.0.1pre
> but doesn't anymore with today's 4.0.2pre.
Actually it is not really as this one works on the mainlin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
20:06 ---
Used to work with 4.1 20050822 but does not with 4.1 20050903.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:03
---
*** Bug 23691 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:03
---
This is actually a duplicate of PR 23771. It compiles fine with 4.0.1pre
but doesn't anymore with today's 4.0.2pre.
W.
*** This bug has been marked as a duplicate of 23771 ***
--
What|Remo
This code
--
template struct length {
static const int value = 3;
};
template ::value> struct S {};
template
S bar (T);
template void foo () {
bar (1);
}
-
Used to compile with gcc 4.0.1pre (20050531), but it doesn't any mor
Currently, the buffers for reading/writing integers
and reals in the i/o library are of type char[], which forces
the use of memcpy(), as in the fix for PR 23356. It would
be better for performance if suitable alignment could be
forced on the buffers.
--
Summary: unaligned buffers in
--
What|Removed |Added
CC||pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:37
---
(In reply to comment #3)
> Unfortunatly I don't believe thats possible without passing extra
> information by more template parameters, which would break binary
> compatability.
In short, in my preliminary opini
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:33
---
(In reply to comment #2)
> Unfortunatly I don't believe thats possible without passing
> extra information by more template parameters, which would break binary
> compatability.
I'm not going to disc
--
What|Removed |Added
CC||chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
--- Additional Comments From chris at bubblescope dot net 2005-09-07 19:22
---
Hmm.. this is I believe a bug, but a very hard one to trigger.
1) This bug is very sensitive. It only occurs if the const_iterator member
function is const and the
iterator member function isn't. It doesn't
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:19
---
(In reply to comment #10)
> one of the key differentiators
> with iostreams is type safety, which is effectively broken with the current
> behavior.
By the way, I don't
--- Additional Comments From ash at onezero dot org 2005-09-07 19:18
---
(Cygwin)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
--- Additional Comments From ash at onezero dot org 2005-09-07 19:18
---
I'm on Cywin and couldn't find a later version of gcc - is there one somewhere
that I can use?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
19:14 ---
3.3.x is old and does not have the inlining improvements that went into 3.4.x.
You might want to try
3.4.x or even 4.0.x. 4.1.x (the mainline) has better inlining still.
But without a full testcase, we
I noticed when compiling with gcc -std=c99 -Winline that this function
inline uint16_t f(uint16_t x) { return x; }
wasn't getting inlined. Inlining is also not done even when the function is
attributed with "__attribute__ ((always_inline))", nor does inlining happen
when there no attribut
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
19:11 ---
Hmm, this works correctly with the C front-end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17256
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:09
---
(In reply to comment #10)
> The behavior we are mimicing isn't printf()'s behavior.
This statement of yours is by and large incorrect, in the face of the actual
way the C++ Standard is formulated. Please read agai
--
What|Removed |Added
Target Milestone|4.0.2 |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16888
--- Additional Comments From jakub at gcc dot gnu dot org 2005-09-07 18:58
---
Looking into it.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub
--- Additional Comments From x at xman dot org 2005-09-07 18:40 ---
The behavior we are mimicing isn't printf()'s behavior. printf() doesn't print
out hexadecimal signed integers as though they were unsigned integers. Intead,
C's type coercion allows the signed integers to be interpreted
--
What|Removed |Added
CC||bug-classpath at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23768
--
What|Removed |Added
Component|libgcj |classpath
Product|gcc |classpath
Version|4.0.1
--
What|Removed |Added
Keywords||alias
Last reconfirmed|2005-07-04 21:36:12 |2005-09-07 18:35:18
date|
The JCE spec for Cipher.doFinal states:
"Upon finishing, this method resets this cipher object to the state it was in
when previously initialized via a call to init. That is, the object is reset and
available to encrypt or decrypt (depending on the operation mode that was
specified in the call to
--- Additional Comments From nico at cam dot org 2005-09-07 18:24 ---
I just tested with HEAD today and the problem doesn't appear to be there any
longer. Therefore gcc 4.1.0 should be OK.
--
What|Removed |Added
---
--
What|Removed |Added
Keywords|missed-optimization |diagnostic
Last reconfirmed|2005-05-16 02:30:28 |2005-09-07 17:43:18
date|
--
What|Removed |Added
Known to fail||3.0.4 3.3.3 3.4.0 4.0.0
Known to work||2.95.3
http://gcc.gnu.org/bugzilla/sh
--- Additional Comments From richard at codesourcery dot com 2005-09-07
17:07 ---
Subject: Re: Functions returning pointers with pointer argument
"tobi at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> I don't have the standard at hand, but both the Intel and the Portland Group
> c
--
What|Removed |Added
Component|c++ |libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
--- Additional Comments From afra at cs dot stanford dot edu 2005-09-07
17:04 ---
Created an attachment (id=9688)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9688&action=view)
complete program showing bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 17:04
---
I don't have the standard at hand, but both the Intel and the Portland Group
compiler accept this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
The following code does not compile. According to the compiler,
't' is overloaded ambiguously.
#include
struct T {
typedef std::vector Vector;
typedef Vector::iterator iterator;
typedef Vector::const_iterator const_iterator;
int t( iterator f) { return *f; }
int t( const
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 17:02
---
Patch here: http://gcc.gnu.org/ml/fortran/2005-09/msg00089.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
16:58 ---
Hmm. I supposed I'd better check. Is the following code
also valid:
program main
implicit none
real, dimension (:), pointer :: x
x => null()
x => test ()
contains
function test
real, dimens
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:51
---
(In reply to comment #8)
> Yes, you have a point that the mapping prescribed by the ISO/IEC Standards is
> not very precise, because, strictly speaking, the C Standard speaks only about
> unsigned int and the C++ S
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:32
---
Fixed for 4.0.2 too.
--
What|Removed |Added
Target Milestone|4.1.0 |4.0.2
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
16:30 ---
Subject: Bug 23358
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 16:30:38
Modified files:
libstdc++-v3 : Change
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:28
---
(In reply to comment #7)
> The ANSI definition for %x (or %X) only covers unsigned integers. Surely then
> doing hex formatting on a signed integer would at the very least be undefined
> behavior.
Yes, you have a
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 16:17
---
Reduced testcase:
common /b/
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-07 16:09
---
(In reply to comment #16)
> Since number 2 is already reported, we only have 3 and 6 left:
I have a patch for 3 and will try to sort out 6 (+pr21986) as soon as I have a
moment.
--
http://gcc.gnu.org/bugz
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
16:07 ---
Confirmed, backtrace:
#0 0x080a2406 in translate_common (common=0x96d29b8, var_list=Variable
"var_list" is not
available.
) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/trans-common.c:879
#1 0x0
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-07
16:07 ---
Can someone ping this patch on the gcc-patches ml?
--
What|Removed |Added
Last reconfirm
--- Additional Comments From x at xman dot org 2005-09-07 16:03 ---
The ANSI definition for %x (or %X) only covers unsigned integers. Surely then
doing hex formatting on a signed integer would at the very least be undefined
behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2375
[EMAIL PROTECTED]:~/src/tests> cat pr16404.f90
REAL, TARGET :: B(2,2)
common x/b/
B = 1.
END
[EMAIL PROTECTED]:~/src/tests> ../gcc/build/gcc/f951 pr16404.f90
MAIN__
pr16404.f90:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if approp
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
15:59 ---
Testing a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rsa
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
15:49 ---
Not a bug as you cannot bind a rvalue to the reference type.
Basicially what you have is:
int g(void);
void h(int&);
void j(void)
{
h(g());
}
And that is invalid. You can bind a rvalue to a const refe
--- Additional Comments From fitzsim at redhat dot com 2005-09-07 15:48
---
I filed a bug against GTK:
http://bugzilla.gnome.org/show_bug.cgi?id=315462
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21598
Trying to compile the following code on a FreeBSD 5.4 machine, using GCC
4.0.1
# 1 "Test.cpp"
# 0 ""
# 1 ""
# 1 "Test.cpp"
class OutStream
{
public:
OutStream();
};
inline OutStream & operator<<( OutStream & output, const int & value )
{
return output;
}
class Client
{
public:
OutStre
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
15:25 ---
Subject: Bug 22555
CVSROOT:/cvs/gcc
Module name:gcc
Branch: improved-aliasing-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 15:25:13
Modified files:
gcc
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-07
14:39 ---
Simplified testcase. This bug is probably a WONTFIX.
int bar (int *);
int foo (void)
{
int x;
__builtin_memset (&x, 0, 32);
return bar (&x);
}
--
What|Removed
1 - 100 of 144 matches
Mail list logo
