--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2006-08-08 06:54
---
Probably this is a dublicate of 27883.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from hubicka at gcc dot gnu dot org 2006-08-08 06:35 ---
The strlen inlining depends on the -mtune switch. -mtune=athlon,generic and
i686
unrolls the strlen by in-line loop, while -mtune=pentium4 use the rep
operation.
Would be possible to benchmark both -mtune=generic an
--- Comment #47 from hubicka at ucw dot cz 2006-08-08 06:28 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code on all
platforms than gcc 3
> In x86/x86-64 world one can be almost sure that the load+execute instruction
> pair will execute (marginaly to noticeably) faste
> In x86/x86-64 world one can be almost sure that the load+execute instruction
> pair will execute (marginaly to noticeably) faster than move+load-and-execute
> instruction pair as the more complex instructions are harder for on-chip
> scheduling (they retire later).
--- Comment #46 from hubicka at gcc dot gnu dot org 2006-08-08 06:15
---
In x86/x86-64 world one can be almost sure that the load+execute instruction
pair will execute (marginaly to noticeably) faster than move+load-and-execute
instruction pair as the more complex instructions are harde
--- Comment #2 from dberlin at gcc dot gnu dot org 2006-08-08 06:14 ---
Subject: Re: redundant phi-node in latch-block
prevents vectorization
pinskia at gcc dot gnu dot org wrote:
> --- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-08 01:47
> ---
> SSA copy prop wit
pinskia at gcc dot gnu dot org wrote:
> --- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-08 01:47
> ---
> SSA copy prop with dce after that should really be the correct way.
>
Err, SSA copy prop should be enough, actually, since after copy-prop,
the phi will have no users (and
--- Comment #45 from whaley at cs dot utsa dot edu 2006-08-08 02:59 ---
Guys,
OK, with Dorit's -fdump-tree-vect-details, I made a little progress on
vectorization. In order to get vectorization to work, I had to add the flag
'-funsafe-math-optimizations'. I will try to create a tarfil
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-08 01:47 ---
SSA copy prop with dce after that should really be the correct way.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-08 01:37 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-08 01:33 ---
fastjar does not exist any more in the mainline and has not for a while now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-08 01:30 ---
gcc_assert (insn_data[(int) icode].n_operands == 3);
(define_expand "reload_incc"
[(parallel [(set (match_operand:CC 2 "integer_register_operand" "=&d")
(match_operand:CC 1 "memory_oper
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-08 01:26 ---
(In reply to comment #7)
> during the gcc "make bootstrap" it seems to be "frozen" at this stage:
I think we can now declare this an ICC bug and close it as invalid.
Please report this to Intel.
--
pinskia at gc
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-08 01:24 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28569
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
GCC build triplet|powerpc-apple-darwin8 |
GCC h
* gcc-4.2.0-20060729
* I configured gcc --program-suffix=42..
* I also have jar in /usr/local/bin (symlink /usr/local/bin/jar@ ->
/usr/local/bin/javavm)
* then, gcc installes as fastjar as jar in /usr/local/bin,
then rename to jar42.
* however when /usr/local/bin/jar exists, installtion fails.
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-08 01:05 ---
Related to PR 27616.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28622
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-08 00:56 ---
I have been having problems with my work machine to be able to test this patch
(before applying it) but hopefuly it will finish this time.
If it does not work, I am going to test it using my home machine.
--
htt
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-08 00:37 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-op
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28634
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28624
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-08 00:33 ---
This is invalid as there are no computed gotos in your example so the compiler
does not know it is a target for a goto so it is able to move the label around.
--
pinskia at gcc dot gnu dot org changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28623
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2006-08-06 17:19:06 |2006-08-08 00:29:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-08 00:29 ---
This sounds like two target problems rather than generic ones.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-08 00:21 ---
We need a testcase to go any further on this bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-08 00:21 ---
*** Bug 28646 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28644
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-08 00:21 ---
*** This bug has been marked as a duplicate of 28644 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-08 00:20 ---
This is a bug in some versions of expect and/or TCL and/or dejagnu.
[EMAIL PROTECTED]:~/src/gcc-3c/checkin/simdmathlibrary$ runtest --version
Expect version is 5.42.1
Tcl version is 8.4
Framework versi
Hi,
I've been trying to run perlbench (speccpu 2006 benchmark) compiled with gcc
4.1.0 with "-O3 -ffast-math -funroll-all-loops -m64". But when I run this
benchmark, it never completes (it goes on more than 3 hours) and I'd to kiil
it.
It completes when I added -fno-inline option. Just wanted to r
Tests in nested directories are run twice, e.g.:
Running .../gcc/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp ...
Running .../gcc/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp ...
Running .../gcc/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp ...
Running .../gcc/gcc/tes
--- Comment #4 from schwab at suse dot de 2006-08-08 00:04 ---
Looks like introduced during the tree-ssa merge.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28636
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-07 23:16 ---
(In reply to comment #4)
> So it looks like point 2 is true.
So it is a latent bug in CSE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28622
--- Comment #4 from schwab at suse dot de 2006-08-07 23:14 ---
The removed comment says:
- /* If will do cse, generate all results into pseudo registers
- since 1) that allows cse to find more things
- and 2) otherwise cse could produce an insn the machine
- cannot support.
--- Comment #5 from schwab at suse dot de 2006-08-07 23:13 ---
Sorry, wrong bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28183
--- Comment #4 from schwab at suse dot de 2006-08-07 23:12 ---
The removed comment says:
- /* If will do cse, generate all results into pseudo registers
- since 1) that allows cse to find more things
- and 2) otherwise cse could produce an insn the machine
- cannot support.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-07 23:09 ---
(In reply to comment #2)
> Broken since r102570:
That would mean a latent bug in the m68k back-end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28622
--- Comment #2 from schwab at suse dot de 2006-08-07 23:00 ---
Broken since r102570:
* expr.c (expand_expr_real_1): Do not load mem targets into register.
* i386.c (ix86_fixup_binary_operands): Likewise.
(ix86_expand_unary_operator): Likewise.
(ix86_expan
--- Comment #9 from cvs-commit at developer dot classpath dot org
2006-08-07 22:24 ---
Subject: Bug 23682
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch: generics-branch
Changes by: Mark Wielaard 06/08/07 22:23:02
Modified files:
.
--- Comment #8 from cvs-commit at developer dot classpath dot org
2006-08-07 22:23 ---
Subject: Bug 23682
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch: classpath-0_92-branch
Changes by: Mark Wielaard 06/08/07 22:22:52
Modified files:
.
--- Comment #1 from tromey at gcc dot gnu dot org 2006-08-07 22:17 ---
On the gcj-eclipse branch, this works for me.
It correctly picks the bootstrap gcj.
However, this not not happening for Andrew Hughes...
--
tromey at gcc dot gnu dot org changed:
What|Removed
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--- Comment #44 from whaley at cs dot utsa dot edu 2006-08-07 21:56 ---
Guys,
OK, the mystery of why my hand-patched gcc didn't work is now cleared up. My
first clue was that neither did the SVN-build gcc! Turns out, your peephole
opt is only done if I throw the flag -O3 rather than -
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-07 21:52 ---
4.1.0 is getting old and 4.1.1 has been released with bugs fixed. And this bug
really has no info about what the problem is.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Hi,
I've been trying to run perlbench (speccpu 2006 benchmark) compiled with gcc
4.1.0 with "-O3 -ffast-math -funroll-all-loops -m64". But when I run this
benchmark, it never completes (it goes on more than 3 hours) and I'd to kiil
it.
It completes when I added -fno-inline option. Just wanted to r
--- Comment #6 from dannysmith at users dot sourceforge dot net 2006-08-07
21:04 ---
(In reply to comment #2)
> (In reply to comment #0)
> precisely, the bug can be reproduced with a combination of --march=pentium-m
> (or --march=pentium3 -msse2), -mfpmath=sse,387, and any optimization
Since the fix for PR26969, we now fail to vectorize loops that have redundant
phi-nodes in their (otherwise empty) latch block.
The testcase committed with the PR fix is an example for such a case.
See http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00034.html for more details.
--
Summar
--- Comment #3 from tromey at gcc dot gnu dot org 2006-08-07 20:39 ---
I took your advice and checked in the result of that cp.
Thanks!
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from tromey at gcc dot gnu dot org 2006-08-07 20:37 ---
Subject: Bug 28609
Author: tromey
Date: Mon Aug 7 20:37:50 2006
New Revision: 116003
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116003
Log:
PR libgcj/28609:
* ltconfig: Copied from gcc.
--- Comment #43 from dorit at il dot ibm dot com 2006-08-07 20:35 ---
> I'm all for this. info gcc says that w/o a guarantee of alignment, loops are
> duped, with an if selecting between vector and scalar loops, is this not
> accurate?
yes
>I spent a day trying to get gcc to vectori
--- Comment #11 from mathieu at malaterre dot com 2006-08-07 20:25 ---
Tested today (Aug 7, 2006) with:
$ /usr/lib/gcc-snapshot/bin/g++ --version
/tmp
g++ (GCC) 4.2.0 20060721 (experimental)
Copy
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--- Comment #2 from apl at alum dot mit dot edu 2006-08-07 18:34 ---
Amending the "description"
attribute ((may_alias)) in a union causes ICE.
I'm using the 7/15/2006 snapshot of 4.2
I realize that unions are implicitly 'aliased', but in fact this problem was
encountered while I w
--
fche at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com
|dot org |
--- Comment #1 from apl at alum dot mit dot edu 2006-08-07 18:27 ---
Created an attachment (id=12040)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12040&action=view)
test case causing ICE
compiled with: g++ -c ice.cxx
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28642
attribute((maybe_aliased)) in a union causes ICE
--
Summary: ICE in layout_type, at stor-layout.c:1851
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unass
--- Comment #2 from hjl at lucon dot org 2006-08-07 18:24 ---
Here is the debug info generated by icc
The section .debug_info contains:
Compilation Unit @ offset 0x0:
Length:272
Version: 2
Abbrev Offset: 0
Pointer Size: 4
<0>: Abbrev Number: 1 (DW_TAG_comp
--- Comment #42 from paolo dot bonzini at lu dot unisi dot ch 2006-08-07
18:19 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
> We should get some idea by comparing gcc3 vs. your
> patched compiler on the various platforms, though oth
--- Comment #8 from pcarlini at suse dot de 2006-08-07 18:16 ---
(In reply to comment #7)
> By the way, as I read the cited LIA-3 draft, it's also consisten with C99. To
> restate my point in a different way, if we believe there is an inconsistency
> between C99 and C++03, then the forme
--- Comment #3 from schwab at suse dot de 2006-08-07 17:51 ---
-floop-optimize2 doesn't help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28636
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28638
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28640
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
The following invalid code snippet triggers an ICE on mainline and 4.1 branch:
===
template void foo();
void bar() { foo<0>(); }
===
bug.cc:1: error: 'void' is not a valid type for a template constant
The following invalid code snippet triggers an ICE on mainline and 4.1 branch:
===
template struct A;
template struct A;
===
bug.cc:1: error: 'void' is not a valid type for a template constant paramete
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-07 17:34 ---
I bet this is a loop.c bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following invalid code snippet triggers a ICE on mainline and 4.1 branch:
===
template struct A
{
static const int i = 1;
char a[i];
};
===
bug.cc:1: error: 'void' is not a valid type for a tem
The following invalid code snippet triggers a ICE on mainline and 4.1 branch:
===
template struct A;
template class> struct B {};
B b;
===
bug.cc:1: error: 'void' is not a valid type for a template c
--- Comment #7 from pcarlini at suse dot de 2006-08-07 17:26 ---
By the way, as I read the cited LIA-3 draft, it's also consisten with C99. To
restate my point in a different way, if we believe there is an inconsistency
between C99 and C++03, then the former can only win about this speci
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-08-07 17:25
---
Lee, this is fallout from your patch for PR 27668.
Would you mind having a look?
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pcarlini at suse dot de 2006-08-07 17:24 ---
(In reply to comment #5)
> Insofar as I understand this issue, it seems that C99 and the C++ standard
> specify different results for the square root of (-1, -0).
>
> If that is correct, then we can decide that we want lib
The following invalid code snippet triggers a segfault on mainline
and 4.1 branch:
===
template struct A {};
A<0> a;
===
bug.cc:1: error: 'void' is not a valid type for a template constant parameter
bug.cc:2: internal compiler error: Segment
--- Comment #41 from whaley at cs dot utsa dot edu 2006-08-07 17:19 ---
Paolo,
>Actually, the peephole phase may not change the register usage, but it
>could peruse a scratch register if available. But it would be much more
>controversial (even if backed by your hard numbers on ATLAS)
--- Comment #5 from ian at airs dot com 2006-08-07 17:14 ---
Insofar as I understand this issue, it seems that C99 and the C++ standard
specify different results for the square root of (-1, -0).
If that is correct, then we can decide that we want libstdc++ to follow C99
rather than the
--- Comment #40 from paolo dot bonzini at lu dot unisi dot ch 2006-08-07
16:58 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
>> I don't see how the last fmul[sl] can be removed without increasing code
>> size.
>>
> However, I c
--- Comment #39 from whaley at cs dot utsa dot edu 2006-08-07 16:47 ---
Paolo,
OK, never mind about all the questions on assembly/patches/SVN/gcc3 perf: I
checked out the main branch, and vi'd the patched file, and I see that your
patch is there. I am presently building the SVN gcc on
--- Comment #3 from tromey at gcc dot gnu dot org 2006-08-07 16:38 ---
Is this fixed by that commit?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28312
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||28067
Status|UNCONFIRMED |NEW
Ever Co
--- Comment #1 from schwab at suse dot de 2006-08-07 16:34 ---
Created an attachment (id=12039)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12039&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28636
$ gcc -O2 input.c -o input
$ ./input
input: input.c:36: main: Assertion `s.buffer_position == s.buffer_end' failed.
The loop loses the increment of s.buffer_position.
--
Summary: [4.0/4.1 regression] Miscompiled loop
Product: gcc
Version: 4.1.2
Statu
--- Comment #8 from tromey at gcc dot gnu dot org 2006-08-07 16:30 ---
I think comment #3 explains the problem.
So, this is either a more general GCC bug, or it is not a bug at all.
In any case it isn't a gcj problem :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28153
--- Comment #4 from Martin dot vGagern at gmx dot net 2006-08-07 16:14
---
(In reply to comment #2)
> I bet this is not a bug. x86 is known to be very register starved.
Yes, I know that. But this situation does not explain, why adding two more
functions containing the asm statements s
--- Comment #3 from Martin dot vGagern at gmx dot net 2006-08-07 16:02
---
One more observation: I tried adding the flags corresponding to -O1 according
to the info page:
-fdefer-pop -fdelayed-branch -fguess-branch-probability -fcprop-registers
-floop-optimize -fif-conversion -fif-conv
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-07 15:53 ---
I bet this is not a bug. x86 is known to be very register starved.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from Martin dot vGagern at gmx dot net 2006-08-07 15:49
---
Created an attachment (id=12038)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12038&action=view)
Testcase demonstrating interference between assembler statements
This test case exhibits the following beha
I was experimenting with the way gcc does register allocation depending on
different flags. I encountered one strange test file where adding a second asm
statement made a first one fail which did work before. Even stranger, when I
have both parts as separate functions before, the combined version c
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-08-07 15:35
---
(In reply to comment #19)
> This patchlet makes GCC use element-copy for struct FF:
You have to be careful when editing count_type_elements so that the elements of
a constructor that are not explict are zeroed.
--- Comment #38 from whaley at cs dot utsa dot edu 2006-08-07 15:32 ---
Paolo,
Thanks for all the help. I'm not sure I understand everything perfectly
though, so there's some questions below . . .
>I don't see how the last fmul[sl] can be removed without increasing code size.
Since t
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-07 15:03 ---
Two things:
1. don't file a bug with a code fragment.
2. this is not a bug as _KERN_STACK can never be unmapped memory at least to
the compiler.
Use the attribute weak and that should fix your issue.
--
pinskia a
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-07 14:54 ---
First patches should be off of the mainline. Second Patchs should be sent to
[EMAIL PROTECTED]
Third and this should be able to fix PR 18031 which I added a patch already
(though not officially sent it because I ha
--- Comment #2 from gbenson at redhat dot com 2006-08-07 14:54 ---
I fixed it now
--
gbenson at redhat dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-08-07 14:50
---
*** Bug 28631 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-07 14:50 ---
GCC 4.1.0 is actually the correct behavior. This is a dup of bug 2922 which
changed the behavior to be what the standard says it should be.
*** This bug has been marked as a duplicate of 2922 ***
--
pinskia at
1 - 100 of 147 matches
Mail list logo
