[Bug target/24959] Trampolines fail on i686-apple-darwin because stack is not executable
--- Comment #11 from echristo at apple dot com 2006-02-27 08:35 --- There are two ways to fix this, the easiest way is to pass -allow_stack_execute through to the linker when we want an executable stack. This is problematic since we'll not be specifying it on the command line. We can turn on an allowable stack at all times, but this is less safe than turning it on only when necessary. The other way is to use mprotect like the patch has below. -- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-11-21 20:49:38 |2006-02-27 08:35:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24959
[Bug driver/26466] multilib selection in gcc driver ignores removal of switches
--- Comment #3 from peb at mppmu dot mpg dot de 2006-02-27 09:08 --- (In reply to comment #2) > Patches goto [EMAIL PROTECTED] with a changelog. Second please update > the patch to the mainline first. > In the meantime I have realized that this problem is fixed in version 4.0.0 (gcc/Changelog.11 entry from 2004-04-17). Why was that fix never ported back to version 3.3.5 (released 2004-09-30) or at least to version 3.4.4 (released 2005-05-19)??? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26466
[Bug libstdc++/26480] [4.2 Regression] No rule to make cstdbool needed by stamp-tr1
--- Comment #2 from pcarlini at suse dot de 2006-02-27 09:45 --- Should be fixed now. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26480
[Bug rtl-optimization/20586] bootstrap comparision fails with -funroll-loops.
--- Comment #4 from pluto at agmk dot net 2006-02-27 10:55 --- still present in 4.1.0-RC2. moreover I see new differences in branch opcodes. --- gcc-stage2.asm 2006-02-27 11:49:00.850323750 +0100 +++ gcc-stage3.asm 2006-02-27 11:49:05.446611000 +0100 @@ -1,5 +1,5 @@ -gcc-stage2.o: file format elf64-x86-64 +gcc-stage3.o: file format elf64-x86-64 Disassembly of section .text: @@ -12848,7 +12848,7 @@ bb87: 80 fa 2a cmp $0x2a,%dl bb8a: 48 89 dd mov %rbx,%rbp bb8d: c6 44 24 6d 00 movb $0x0,0x6d(%rsp) - bb92: 0f 84 10 04 00 00 je bfa8 + bb92: 0f 84 0b 04 00 00 je bfa3 bb98: 0f b6 4d 00 movzbl 0x0(%rbp),%ecx bb9c: 80 f9 09 cmp $0x9,%cl bb9f: 41 0f 94 c0 sete %r8b @@ -12911,7 +12911,7 @@ bc70: 40 0a b4 24 90 00 00 or 0x90(%rsp),%sil bc77: 00 bc78: 88 8c 24 a0 00 00 00 mov %cl,0xa0(%rsp) - bc7f: 0f 84 31 03 00 00 je bfb6 + bc7f: 0f 84 2c 03 00 00 je bfb1 bc85: c6 44 24 6f 00 movb $0x0,0x6f(%rsp) bc8a: 80 7d 00 3a cmpb $0x3a,0x0(%rbp) bc8e: 0f 84 7b 06 00 00 je c30f @@ -12956,7 +12956,7 @@ bd24: 45 85 f6 test %r14d,%r14d bd27: 44 89 bc 24 bc 00 00 mov %r15d,0xbc(%rsp) bd2e: 00 - bd2f: 0f 8e 57 02 00 00 jle bf8c + bd2f: 0f 8e 52 02 00 00 jle bf87 bd35: 48 8b 1d 00 00 00 00 mov 0(%rip),%rbx # bd3c bd3c: 44 8b bc 24 c0 00 00 mov 0xc0(%rsp),%r15d bd43: 00 @@ -12985,7 +12985,7 @@ bd8f: 41 ff c5 inc %r13d bd92: 44 3b ac 24 c0 00 00 cmp 0xc0(%rsp),%r13d bd99: 00 - bd9a: 0f 84 ec 01 00 00 je bf8c + bd9a: 0f 84 e7 01 00 00 je bf87 bda0: 45 85 ff test %r15d,%r15d bda3: 0f 84 e5 00 00 00 je be8e bda9: 41 83 ff 01 cmp $0x1,%r15d @@ -13055,7 +13055,7 @@ be7c: 48 83 c3 18 add $0x18,%rbx be80: 44 3b ac 24 c0 00 00 cmp 0xc0(%rsp),%r13d be87: 00 - be88: 0f 84 fe 00 00 00 je bf8c + be88: 0f 84 f9 00 00 00 je bf87 be8e: 4c 8b 3b mov (%rbx),%r15 be91: 4c 89 f2 mov %r14,%rdx be94: 4c 89 e6 mov %r12,%rsi @@ -13070,206 +13070,206 @@ beb9: 4c 8d 7b 18 lea 0x18(%rbx),%r15 bebd: 41 ff c5 inc %r13d bec0: 4c 89 f2 mov %r14,%rdx - bec3: 44 89 6c 24 40 mov %r13d,0x40(%rsp) + bec3: 44 89 6c 24 3c mov %r13d,0x3c(%rsp) bec8: 4c 89 e6 mov %r12,%rsi becb: 49 8b 1f mov (%r15),%rbx - bece: 4c 89 7c 24 38 mov %r15,0x38(%rsp) + bece: 4c 89 7c 24 30 mov %r15,0x30(%rsp) bed3: 48 89 df mov %rbx,%rdi bed6: e8 00 00 00 00 callq bedb bedb: 85 c0 test %eax,%eax bedd: 75 17 jne bef6 bedf: 80 7c 24 6d 00 cmpb $0x0,0x6d(%rsp) - bee4: 0f 85 b9 03 00 00 jne c2a3 + bee4: 0f 85 b8 03 00 00 jne c2a2 beea: 42 80 3c 33 00 cmpb $0x0,(%rbx,%r14,1) beef: 90 nop - bef0: 0f 84 ad 03 00 00 je c2a3 - bef6: 4d 8d 4f 18 lea 0x18(%r15),%r9 - befa: 45 8d 55 01 lea 0x1(%r13),%r10d + bef0: 0f 84 ac 03 00 00 je c2a2 + bef6: 49 8d 7f 18 lea 0x18(%r15),%rdi + befa: 41 8d 5d 01 lea 0x1(%r13),%ebx befe: 4c 89 f2 mov %r14,%rdx bf01: 4c 89 e6 mov %r12,%rsi - bf04: 49 8b 19 mov (%r9),%rbx - bf07: 44 89 54 24 20 mov %r10d,0x20(%rsp) - bf0c: 4c 89 4c 24 18 mov %r9,0x18(%rsp) - bf11: 48 89 df mov %rbx,%rdi - bf14: e8 00 00 00 00 callq bf19 - bf19: 85 c0 test %eax,%eax - bf1b: 75 19 jne bf36 - bf1d: 80 7c 24 6d 00 cmpb $0x0,0x6d(%rsp) - bf22: 0f 85 a1 03 00 00 jne c2c9 - bf28: 42 80 3c 33 00 cmpb $0x0,(%rbx,%r14,1) + bf04: 89 5c 24 18 mov %ebx,0x18(%rsp) + bf08: 48 8b 1f mov (%rdi),%rbx + bf0b: 48 89 7c 24 10 mov %rdi,0x10(%rsp) + bf10: 48 89 df
[Bug bootstrap/26481] New: Problem bootstraping gcc-4.1.0-20060219 multilib libstdc++ on 32bit AIX 5.1
Bootstrap problem in GCC 4.1.0 RC1 gcc-4.1.0-20060219 configure call: ../configure --prefix=/opt/oss/apps/gcc-4.1.0-20060219 --enable-threads --disable-aix64 build call: gmake bootstrap using GNU make instead of AIX make /scratch/build/gcc-4.1.0-20060219/objdir/./gcc/xgcc -shared-libgcc -B/scratch/build/gcc-4.1.0-20060219/objdir/./gcc -nostdinc++ -L/scratch/build/gcc-4.1.0-20060219/objdir/powerpc-ibm-aix5.1.0.0/power/libstdc++-v3/src -L/scratch/build/gcc-4.1.0-20060219/objdir/powerpc-ibm-aix5.1.0.0/power/libstdc++-v3/src/.libs -B/opt/oss/gcc-4.1.0-20060219/powerpc-ibm-aix5.1.0.0/bin/ -B/opt/oss/gcc-4.1.0-20060219/powerpc-ibm-aix5.1.0.0/lib/ -isystem /opt/oss/gcc-4.1.0-20060219/powerpc-ibm-aix5.1.0.0/include -isystem /opt/oss/gcc-4.1.0-20060219/powerpc-ibm-aix5.1.0.0/sys-include -mcpu=power -I/scratch/build/gcc-4.1.0-20060219/objdir/powerpc-ibm-aix5.1.0.0/power/libstdc++-v3/include/powerpc-ibm-aix5.1.0.0 -I/scratch/build/gcc-4.1.0-20060219/objdir/powerpc-ibm-aix5.1.0.0/power/libstdc++-v3/include -I/scratch/build/gcc-4.1.0-20060219/libstdc++-v3/libsupc++ -g -O2 -mcpu=power -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -I/scratch/build/gcc-4.1.0-20060219/objdir/powerpc-ibm-aix5.1.0.0/power/libstdc++-v3/include/backward -Wno-deprecated -c ../../../../../libstdc++-v3/src/strstream.cc -DPIC -o .libs/strstream.o ../../../../../libstdc++-v3/src/strstream.cc:1: warning: -ffunction-sections may affect debugging on some targets ../../../../../libstdc++-v3/src/strstream.cc: In member function 'virtual std::streampos std::strstreambuf::seekpos(std::streampos, std::_Ios_Openmode)': ../../../../../libstdc++-v3/src/strstream.cc:299: error: unrecognizable insn: (insn 5 4 6 0 ../../../../../libstdc++-v3/src/strstream.cc:298 (parallel [ (set (reg:SI 126) (reg:SI 5 5)) (clobber (scratch:SI)) (set (mem/s/c:SI (plus:SI (reg/f:SI 115 virtual-stack-vars) (const_int 4 [0x4])) [62 pos+4 S4 A32]) (reg:SI 6 6)) (set (mem/s/c:SI (plus:SI (reg/f:SI 115 virtual-stack-vars) (const_int 8 [0x8])) [62 pos+8 S4 A64]) (reg:SI 7 7)) (set (mem/s/c:SI (plus:SI (reg/f:SI 115 virtual-stack-vars) (const_int 12 [0xc])) [62 pos+12 S4 A32]) (reg:SI 8 8)) ]) -1 (nil) (nil)) ../../../../../libstdc++-v3/src/strstream.cc:299: internal compiler error: in instantiate_virtual_regs_in_insn, at function.c:1555 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. gmake[9]: *** [strstream.lo] Error 1 gmake[9]: Leaving directory `/scratch/build/gcc-4.1.0-20060219/objdir/powerpc-ibm-aix5.1.0.0/power/libstdc++-v3/src' gmake[8]: *** [all-recursive] Error 1 gmake[8]: Leaving directory `/scratch/build/gcc-4.1.0-20060219/objdir/powerpc-ibm-aix5.1.0.0/power/libstdc++-v3' gmake[7]: *** [all] Error 2 gmake[7]: Leaving directory `/scratch/build/gcc-4.1.0-20060219/objdir/powerpc-ibm-aix5.1.0.0/power/libstdc++-v3' gmake[6]: *** [multi-do] Error 1 gmake[6]: Leaving directory `/scratch/build/gcc-4.1.0-20060219/objdir/powerpc-ibm-aix5.1.0.0/libstdc++-v3' gmake[5]: *** [all-multi] Error 2 gmake[5]: Leaving directory `/scratch/build/gcc-4.1.0-20060219/objdir/powerpc-ibm-aix5.1.0.0/libstdc++-v3' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/scratch/build/gcc-4.1.0-20060219/objdir/powerpc-ibm-aix5.1.0.0/libstdc++-v3' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/scratch/build/gcc-4.1.0-20060219/objdir/powerpc-ibm-aix5.1.0.0/libstdc++-v3' gmake[2]: *** [all-target-libstdc++-v3] Error 2 gmake[2]: Leaving directory `/scratch/build/gcc-4.1.0-20060219/objdir' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/scratch/build/gcc-4.1.0-20060219/objdir' gmake: *** [bootstrap] Error 2 -- Summary: Problem bootstraping gcc-4.1.0-20060219 multilib libstdc++ on 32bit AIX 5.1 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andreasc at neuro dot informatik dot uni-kassel dot de GCC build triplet: powerpc-ibm-aix5.1.0.0 GCC host triplet: powerpc-ibm-aix5.1.0.0 GCC target triplet: powerpc-ibm-aix5.1.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26481
[Bug bootstrap/26481] Problem bootstraping gcc-4.1.0-20060219 multilib libstdc++ on 32bit AIX 5.1
--- Comment #1 from andreasc at neuro dot informatik dot uni-kassel dot de 2006-02-27 11:24 --- Created an attachment (id=10918) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10918&action=view) build log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26481
[Bug target/26474] compiling 'long long' math with optimization gives bad results
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-27 11:42 --- Works for me on i686 for all gcc > 3.3.3 and 2.95. Works for me on ppc64 with 4.1.0. So this is at least ppc specific. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|other |target GCC build triplet|3.2.1 | GCC target triplet||ppc-linux Keywords||wrong-code Known to work||4.1.0 Version|3.2.1 |3.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26474
[Bug target/26474] compiling 'long long' math with optimization gives bad results
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-27 11:47 --- Confirmed for 3.3.3-hammer on ppc32 (ppc64 works). 4.0.2 is fine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.3.3 Known to work|4.1.0 |4.0.2 4.1.0 Last reconfirmed|-00-00 00:00:00 |2006-02-27 11:47:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26474
[Bug target/24959] Trampolines fail on i686-apple-darwin because stack is not executable
--- Comment #12 from gcc at microbizz dot nl 2006-02-27 12:03 --- Subject: Re: Trampolines fail on i686-apple-darwin because stack is not executable I agree that calling mprotect is the best fix. Adriaan van Os -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24959
[Bug libstdc++/14866] 27_io/ios_base/sync_with_stdio/1.cc is broken on simulator testglue targets
--- Comment #1 from paolo at gcc dot gnu dot org 2006-02-27 12:38 --- Subject: Bug 14866 Author: paolo Date: Mon Feb 27 12:38:49 2006 New Revision: 111474 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111474 Log: 2006-02-27 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/14866 * testsuite/27_io/ios_base/sync_with_stdio/1.cc: Redirect stderr instead. Modified: trunk/libstdc++-v3/testsuite/27_io/ios_base/sync_with_stdio/1.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14866
[Bug libstdc++/14866] 27_io/ios_base/sync_with_stdio/1.cc is broken on simulator testglue targets
--- Comment #2 from paolo at gcc dot gnu dot org 2006-02-27 12:39 --- Subject: Bug 14866 Author: paolo Date: Mon Feb 27 12:39:27 2006 New Revision: 111475 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111475 Log: 2006-02-27 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/14866 * testsuite/27_io/ios_base/sync_with_stdio/1.cc: Redirect stderr instead. Modified: trunk/libstdc++-v3/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14866
[Bug libstdc++/14866] 27_io/ios_base/sync_with_stdio/1.cc is broken on simulator testglue targets
--- Comment #3 from pcarlini at suse dot de 2006-02-27 12:40 --- Fixed for 4.2.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14866
[Bug target/26474] compiling 'long long' math with optimization gives bad results
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-02-27 13:28 --- Fixed at least on the 3.4 branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work|4.0.2 4.1.0 |3.4.6 4.0.2 4.1.0 Resolution||FIXED Target Milestone|--- |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26474
[Bug tree-optimization/13876] loop not fully optimized
--- Comment #5 from steven at gcc dot gnu dot org 2006-02-27 13:48 --- Could it be that this is now fixed? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13876
[Bug libstdc++/25626] Valarray vs non-POD
--- Comment #3 from jakub at gcc dot gnu dot org 2006-02-27 13:53 --- Subject: Bug 25626 Author: jakub Date: Mon Feb 27 13:52:58 2006 New Revision: 111481 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111481 Log: 2006-01-15 Paolo Carlini <[EMAIL PROTECTED]> Gabriel Dos Reis <[EMAIL PROTECTED]> PR libstdc++/25626 * include/std/std_valarray.h (valarray(const slice_array<>&), valarray(const gslice_array<>&), valarray(const mask_array<>&), valarray(const indirect_array<>&), valarray(const _Expr<>&)): Forward to __valarray_copy_construct, not __valarray_copy. * include/bits/valarray_array.h (__valarray_copy_construct(_Array<>, _Array<>, _Array<>, size_t), __valarray_copy_construct(_Array<>, size_t, size_t, _Array<>)): New. Modified: branches/redhat/gcc-4_1-branch/libstdc++-v3/ChangeLog branches/redhat/gcc-4_1-branch/libstdc++-v3/include/bits/valarray_array.h branches/redhat/gcc-4_1-branch/libstdc++-v3/include/std/std_valarray.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25626
[Bug middle-end/7561] Prefetch merging code in gcc-3.1/gcc/loop.c incorect
--- Comment #7 from steven at gcc dot gnu dot org 2006-02-27 13:53 --- This will never be fixed. For the trunk (gcc 4.2 to be), the prefetching pass has been replaced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7561
[Bug middle-end/7561] Prefetch merging code in gcc-3.1/gcc/loop.c incorect
--- Comment #8 from steven at gcc dot gnu dot org 2006-02-27 13:54 --- And I forgot: ...therefor, closing. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7561
[Bug rtl-optimization/11707] [3.4 Regression] [new unroller] constants not propagated in unrolled loop iterations with a conditional
--- Comment #21 from steven at gcc dot gnu dot org 2006-02-27 13:55 --- With the old loop optimizer gone, moving jump bypassing after loop2 is a quite reasonable thing to do. Richi, now you have the chance to get your patch in after all, if it's still useful. Other good thing about it: Maybe this makes another RTL jump threading pass (the one after loop2) even more unuseful... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11707
[Bug rtl-optimization/13300] [3.4 regression] Variable incorrectly identified as a biv
--- Comment #9 from steven at gcc dot gnu dot org 2006-02-27 13:56 --- The old RTL loop optimizer is no more in gcc 4.2, so the bug can't show itself there. -- steven at gcc dot gnu dot org changed: What|Removed |Added Known to work|2.95.4 |2.95.4 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13300
[Bug tree-optimization/21513] [4.0/4.1/4.2 Regression] __builtin_expect getting in the way of uninitialized warnings
--- Comment #6 from steven at gcc dot gnu dot org 2006-02-27 13:58 --- Should be fixed by removing the old RTL loop optimizer. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21513
[Bug middle-end/22366] [meta-bug] issues related to the removal of loop.c
--- Comment #8 from steven at gcc dot gnu dot org 2006-02-27 14:01 --- The old RTL loop optimizer is no more on the trunk, so there is no reason to keep this meta-bug open. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22366
[Bug driver/26466] multilib selection in gcc driver ignores removal of switches
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-27 14:01 --- Fixed by: http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02011.html This was not a regression so closing as fixed as per GCC's development guide lines. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26466
[Bug target/26481] Problem bootstraping gcc-4.1.0-20060219 multilib libstdc++ on 32bit AIX 5.1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-27 14:03 --- Can you attach the preprocessed source as requested by: http://gcc.gnu.org/bugs.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26481
[Bug rtl-optimization/11707] [3.4 Regression] [new unroller] constants not propagated in unrolled loop iterations with a conditional
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-02-27 14:03 --- I don't know - the original testcase was fixed by tree-ssa merge, so, apart from a general pass ordering overhaul there's nothing to be done for this particular bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11707
[Bug rtl-optimization/24814] unrolling doesn't put loop notes in right place
--- Comment #4 from steven at gcc dot gnu dot org 2006-02-27 14:04 --- Actually there is nothing that uses LOOP_NOTEs other than the old RTL loop optimizer. At least, nothing that _should_ use it. Wanna know about loops? Find natural loops instead of depending on the notes. But the point is moot, the old RTL loop optimizer is no more. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24814
[Bug tree-optimization/22041] Reverse loop order for increased efficiency
--- Comment #3 from steven at gcc dot gnu dot org 2006-02-27 14:06 --- Dunno if tree loop reversal is already there, but Zdenek probably likes to know what bugs he is fixing... -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22041
[Bug libstdc++/26482] New: make[4]: *** No rule to make target `/mnt/gnu/gcc-3.3/gcc/libstdc++-v3/include/tr1/cstdbool'
make[2]: Entering directory `/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libst dc++-v3' make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc -D_XOPEN_UNIX -D_XOPEN_SOURCE_EXTENDED -D_I NCLUDE__STDC_A1_SOURCE -D_INCLUDE_XOPEN_SOURCE_500" "CC_FOR_TARGET=/mnt/gnu/gcc- 3.3/objdir/./gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/./gcc/ -B/opt/gnu/gcc/gcc-4.2.0/ hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/lib/ - isystem /opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/g cc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/sys-include" "CFLAGS=-O2 -O2 " "CXXFLAGS=-g - O2 " "CFLAGS_FOR_BUILD=-O2" "CFLAGS_FOR_TARGET=-O2 -O2 " "INSTALL=/opt/gnu/bin/i nstall -c" "INSTALL_DATA=/opt/gnu/bin/install -c -m 644" "INSTALL_PROGRAM=/opt/g nu/bin/install -c" "INSTALL_SCRIPT=/opt/gnu/bin/install -c" "LDFLAGS=" "LIBCFLAG S=-O2 -O2 " "LIBCFLAGS_FOR_TARGET=-O2 -O2 " "MAKE=make" "MAKEINFO=makeinfo --spl it-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/ bin/sh" "RUNTESTFLAGS=" "exec_prefix=/opt/gnu/gcc/gcc-4.2.0" "infodir=/opt/gnu/g cc/gcc-4.2.0/info" "libdir=/opt/gnu/gcc/gcc-4.2.0/lib" "includedir=/opt/gnu/gcc/ gcc-4.2.0/include" "prefix=/opt/gnu/gcc/gcc-4.2.0" "tooldir=/opt/gnu/gcc/gcc-4.2 .0/hppa2.0w-hp-hpux11.11" "gxx_include_dir=/opt/gnu/gcc/gcc-4.2.0/include/c++/4. 2.0" "AR=/usr/ccs/bin/ar" "AS=/mnt/gnu/gcc-3.3/objdir/./gcc/as" "LD=/mnt/gnu/gcc -3.3/objdir/./gcc/collect-ld" "RANLIB=/usr/ccs/bin/ranlib" "NM=/mnt/gnu/gcc-3.3/ objdir/./gcc/nm" "NM_FOR_BUILD=" "NM_FOR_TARGET=/usr/ccs/bin/nm" "DESTDIR=" "WER ROR=" all-recursive make[3]: Entering directory `/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libst dc++-v3' Making all in include make[4]: Entering directory `/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libst dc++-v3/include' make[4]: *** No rule to make target `/mnt/gnu/gcc-3.3/gcc/libstdc++-v3/include/t r1/cstdbool', needed by `stamp-tr1'. Stop. make[4]: Leaving directory `/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libstd c++-v3/include' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libstd c++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libstd c++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/mnt/gnu/gcc-3.3/objdir' make: *** [bootstrap] Error 2 Mon Feb 27 03:43:29 EST 2006 -- Summary: make[4]: *** No rule to make target `/mnt/gnu/gcc- 3.3/gcc/libstdc++-v3/include/tr1/cstdbool' Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26482
[Bug libstdc++/26482] make[4]: *** No rule to make target `/mnt/gnu/gcc-3.3/gcc/libstdc++-v3/include/tr1/cstdbool'
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-27 14:08 --- http://gcc.gnu.org/ml/gcc-cvs/2006-02/msg01021.html *** This bug has been marked as a duplicate of 26480 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26482
[Bug libstdc++/26480] [4.2 Regression] No rule to make cstdbool needed by stamp-tr1
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-27 14:08 --- *** Bug 26482 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26480
[Bug rtl-optimization/13300] [3.4 regression] Variable incorrectly identified as a biv
--- Comment #10 from rsandifo at gcc dot gnu dot org 2006-02-27 14:08 --- "steven at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > The old RTL loop optimizer is no more in gcc 4.2, so the bug can't > show itself there. And there was much rejoicing! I was only keeping this bug open to track the unsafe assumption: there are no known testcases that trip over it now, and it isn't something we could change on a release branch. So let's close this as fixed. Richard -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13300
[Bug other/26473] [4.1/4.2 Regression] cross-building installs ssp headers to $(includedir)
--- Comment #2 from ralf dot corsepius at rtems dot org 2006-02-27 14:11
---
IMO, the cause is clear: The toplevel configure script is broken.
Rationale:
1. libssp/* applies a standard automake-based configuration. i.e. includedir is
supposed to be pointing to the final $includedir, i.e. libssp/configure.ac
expects
--includedir=${exec_prefix}/${target_alias}/include for cross compilation
The toplevel configure script however (bogusly) passes
--includedir=$(includedir) [here /usr/local/include] in TARGET_CONFIGARGS,
which causes libssp/configure to receive a bogus includedir.
(Check for includedir in $target_alias/libssp/{config.status|Makefile} of a
configured build tree)
=> Adding --includedir=${exec_prefix}/${target_alias}/include to
TARGET_CONFIGARGS would be a work-around.
But then, ... the next bug hits:
2. The toplevel configure script exports includedir=$(includedir).
This bogusly overrides includedir again.
To overcome both issues, I am proposing the patch in the attachment.
ATM, this patch is tested with --languages=c --target=sparc-rtems4.7, only, but
I'd expect this patch also to resolve the mudflap rsp. gomp headers issues.
--
ralf dot corsepius at rtems dot org changed:
What|Removed |Added
CC||joel at oarcorp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26473
[Bug target/26481] Problem bootstraping gcc-4.1.0-20060219 multilib libstdc++ on 32bit AIX 5.1
--- Comment #3 from andreasc at neuro dot informatik dot uni-kassel dot de 2006-02-27 14:12 --- Created an attachment (id=10919) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10919&action=view) precompiled sourcecode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26481
[Bug rtl-optimization/24497] [3.4/4.0 Regression] internal compiler error: in apply_opt_in_copies, at loop-unroll.c:2122
--- Comment #7 from steven at gcc dot gnu dot org 2006-02-27 14:12 --- Was this fixed with the patch in comment #6? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24497
[Bug other/26473] [4.1/4.2 Regression] cross-building installs ssp headers to $(includedir)
--- Comment #3 from ralf dot corsepius at rtems dot org 2006-02-27 14:12 --- Created an attachment (id=10920) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10920&action=view) Before mentioned patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26473
[Bug tree-optimization/13876] loop not fully optimized
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-27 14:14 --- (In reply to comment #5) > Could it be that this is now fixed? Nope, the second testcase in comment #2 is still very obvious missing an optimization with respect with jump threading: cmpw cr7,r31,r30 li r3,0 cmpwi cr6,r3,0 bne+ cr7,L6 L6: beq- cr6,L4 That is only time I have seen an missed optimization that is so obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13876
[Bug rtl-optimization/13712] Executable runs 25% slower than when compiled with INTEL compiler
--- Comment #17 from steven at gcc dot gnu dot org 2006-02-27 14:22 --- For -D__NO_MATH_INLINES we're probably not going to make any progress as long as Uli is the glibc maintainer. Other than that, this appears to be fixed. Note that ICC has -ffast-math and SSE as the defaults, where GCC choses for safe math and code that works on any ix86 CPU, not just the ones with SSE. So if there is still a significant difference, it is as much philosophical as it is in code generation. Given the right set of options, GCC can compete with ICC on my Pentium4 box, and on Uros' box. So there doesn't seem to be a good reason to keep this report open. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13712
[Bug rtl-optimization/13712] Executable runs 25% slower than when compiled with INTEL compiler
--- Comment #18 from steven at gcc dot gnu dot org 2006-02-27 14:22 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13712
[Bug target/26481] Problem bootstraping gcc-4.1.0-20060219 multilib libstdc++ on 32bit AIX 5.1
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-27 14:41 --- Reducing (I can reproduce this ICE on the mainline with a cross compiler). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc-ibm-aix5.1.0.0 | GCC host triplet|powerpc-ibm-aix5.1.0.0 | Known to fail||4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26481
[Bug driver/26466] multilib selection in gcc driver ignores removal of switches
--- Comment #5 from peb at mppmu dot mpg dot de 2006-02-27 14:49 --- (In reply to comment #4) > Fixed by: > http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02011.html > > This was not a regression so closing as fixed as per GCC's development guide > lines. > It would be nice if you could apply that patch to the current 3.4.x (and 3.3.x?) version, with a ChangeLog entry refering to the original author. -- peb at mppmu dot mpg dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26466
[Bug driver/26466] [3.4 only] multilib selection in gcc driver ignores removal of switches
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-27 14:51 --- Fine, then the last release of 3.4.x is comming so, it might make it into it but I doubt it, post the backport to [EMAIL PROTECTED] and maybe the release manager for 3.4 will approve it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-27 14:51:34 date|| Summary|multilib selection in gcc |[3.4 only] multilib |driver ignores removal of |selection in gcc driver |switches|ignores removal of switches Target Milestone|4.0.0 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26466
[Bug libfortran/26464] Runtime I/O error/invald argument on READ
--- Comment #4 from dir at lanl dot gov 2006-02-27 14:55 --- It looks like you got it this time. I tried all of the previous tests with good results and I randomly tested a few hundred different I/O blocks size between 2 and 1 with out finding any errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26464
[Bug target/26481] ICE with -mcpu=power and struct passing
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-27 15:54 ---
Confirmed, reduced testcase:
struct fpos {
long long _M_off;
char * _M_state;
};
fpos seekpos(fpos pos, int){}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-02-27 15:54:59
date||
Summary|Problem bootstraping gcc- |ICE with -mcpu=power and
|4.1.0-20060219 multilib |struct passing
|libstdc++ on 32bit AIX 5.1 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26481
[Bug target/26481] ICE with -mcpu=power and struct passing
--- Comment #6 from dje at gcc dot gnu dot org 2006-02-27 16:07 --- This is the same problem that has been recurring when compiling with POWER for a while. This is the first time that it has been reported to affect bootstrap. The problem is that GCC does not re-recognize the store_multiple_power pattern. The original POWER architecture no longer is supported, so not much attention is paid to POWER architecture code generation. The best solution probably is to disable the "power" multilib in GCC 4.1.1. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26481
[Bug fortran/26393] ICE with function returning variable lenght array
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-02-27
16:10 ---
I have a fix that I will post tonight but it appears below anyway.
Paul
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(r├®vision 111471)
+++ gcc/fortran/trans-decl.c(copie de travail)
@@ -846,7 +846,8 @@
tree length = NULL_TREE;
int byref;
- gcc_assert (sym->attr.referenced);
+ gcc_assert (sym->attr.referenced
+ || sym->ns->proc_name->attr.if_source == IFSRC_IFBODY);
if (sym->ns && sym->ns->proc_name->attr.function)
byref = gfc_return_by_reference (sym->ns->proc_name);
and the testcase
! { dg-do run }
! Tests the fix for PR26393, in which an ICE would occur in trans-decl.c
! (gfc_get_symbol_decl) because anzKomponenten is not referenced in the
! interface for solveCConvert. The solution was to assert that the symbol
! is either referenced or in an interface body.
!
! Based on the testcase in the PR.
!
MODULE MODULE_CONC
INTEGER, SAVE :: anzKomponenten = 2
END MODULE MODULE_CONC
MODULE MODULE_THERMOCALC
INTERFACE
FUNCTION solveCConvert ()
USE MODULE_CONC, ONLY: anzKomponenten
REAL :: solveCConvert(1:anzKomponenten)
END FUNCTION solveCConvert
END INTERFACE
END MODULE MODULE_THERMOCALC
SUBROUTINE outDiffKoeff
USE MODULE_CONC
USE MODULE_THERMOCALC
REAL :: buffer_conc(1:anzKomponenten)
buffer_conc = solveCConvert ()
if (any(buffer_conc .ne. (/(real(i), i = 1, anzKomponenten)/))) &
call abort ()
END SUBROUTINE outDiffKoeff
program missing_ref
USE MODULE_CONC
call outDiffKoeff
! Now set anzKomponenten to a value that would cause a segfault if
! buffer_conc and solveCConvert did not have the correct allocation
! of memory.
anzKomponenten = 5000
call outDiffKoeff
end program missing_ref
FUNCTION solveCConvert ()
USE MODULE_CONC, ONLY: anzKomponenten
REAL :: solveCConvert(1:anzKomponenten)
solveCConvert = (/(real(i), i = 1, anzKomponenten)/)
END FUNCTION solveCConvert
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26393
[Bug libgcj/26483] New: Wrong parsing of doubles when interpreted
I tried to run the attached test case on IA64 native and interpreted. The bad news is that both give totally different results: Native: [EMAIL PROTECTED]:~$ gcj-4.0 DoubleTest.java -o doubleTest --main=DoubleTest -g [EMAIL PROTECTED]:~$ ./doubleTest 5.0E-324 Interpreted: [EMAIL PROTECTED]:~$ gij-4.0 DoubleTest 8.881784197001252E-16 The interpreted case is wrong. This seems to be a bug in fdlibm as jamvm/classpath has the same bug. This bug only happens on IA64 as far as I know. E.g. it makes building GNU classpath fail with ecj. I wonder what GCJ does that makes this work in the native case ... -- Summary: Wrong parsing of doubles when interpreted Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: konqueror at gmx dot de GCC build triplet: ia64-linux-gnu GCC host triplet: ia64-linux-gnu GCC target triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted
--- Comment #1 from konqueror at gmx dot de 2006-02-27 16:20 --- Created an attachment (id=10921) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10921&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/25414] should update rmic
--- Comment #2 from greenrd at gcc dot gnu dot org 2006-02-27 16:59 --- Another reason to update rmic is that the current rmic ignores its -classpath argument. -- greenrd at gcc dot gnu dot org changed: What|Removed |Added CC||greenrd at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25414
[Bug libgcj/26483] Wrong parsing of doubles when interpreted
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-27 17:03 --- Isn't this the "64bit" issue with fdlibm? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug c/26484] New: GCC 3.4.5 fails to build on intel mac
bootstrapping GCC 3.4.5 (using the gcc4.0 compiler) fails with the following
error:
(SHLIB_LINK='' \
SHLIB_MULTILIB=''; \
gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-error -DHAVE_CONFIG_H
-I. -I. -I. -I./. -I./../include -I../intl \
-DSTANDARD_STARTFILE_PREFIX=\"../../../\"
-DSTANDARD_EXEC_PREFIX=\"/usr/lib/gcc/\"
-DSTANDARD_LIBEXEC_PREFIX=\"/usr/libexec/gcc/\"
-DDEFAULT_TARGET_VERSION=\"3.4.5\"
-DDEFAULT_TARGET_MACHINE=\"i686-apple-darwin8.5.2\"
-DSTANDARD_BINDIR_PREFIX=\"/usr/bin/\" -DTOOLDIR_BASE_PREFIX=\"../../../../\"
`test "X${SHLIB_LINK}" = "X" || test "yes" != "yes" || echo
"-DENABLE_SHARED_LIBGCC"` `test "X${SHLIB_MULTILIB}" = "X" || echo
"-DNO_SHARED_LIBGCC_MULTILIB"` \
-c ./gcc.c -o gcc.o)
./gcc.c:714: warning: string length '2483' is greater than the length '509' ISO
C89 compilers are required to support
./gcc.c:721: warning: string length '636' is greater than the length '509' ISO
C89 compilers are required to support
./gcc.c:904: warning: string length '529' is greater than the length '509' ISO
C89 compilers are required to support
./gcc.c:922: warning: string length '608' is greater than the length '509' ISO
C89 compilers are required to support
./gcc.c:1093: error: parse error before ',' token
./gcc.c:1504: warning: string length '833' is greater than the length '509' ISO
C89 compilers are required to support
make[2]: *** [gcc.o] Error 1
make[1]: *** [stage1_build] Error 2
make: *** [bootstrap] Error 2
the problem is in gcc/config/darwin.h, in the TARGET_OPTION_TRANSLATE_TABLE
macro. This macro ends with ", SUBTARGET_OPTION_TRANSLATE_TABLE", but
SUBTARGET... is empty, so gcc doesn't like the trailing comma.
--
Summary: GCC 3.4.5 fails to build on intel mac
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at junk dot kraney dot com
GCC host triplet: i686-apple-darwin8.5.2
GCC target triplet: i686-apple-darwin8.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26484
[Bug target/26484] GCC 3.4.5 fails to build on intel mac
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-27 17:18 --- Fixed for the mainline (4.2.0) and not going to be fixed for any other branch. The port was fundematly broken before that point. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26484
[Bug bootstrap/26485] New: gcc 3.4.5 bootstrap fails w/ "unrecognizable insn" on intel mac
I'm bootstrapping gcc 3.4.5 using the gcc 4.0 compiler on a macbook.
The boostrap compile fails with the following error:
gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long-DHAVE_CONFIG_H -o cc1 \
c-parse.o c-lang.o c-pretty-print.o stub-objc.o attribs.o c-errors.o
c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o
c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o
c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o libcpp.a darwin-c.o
main.o libbackend.a ../libiberty/libiberty.a ../intl/libintl.a
/usr/lib/libiconv.dylib -liconv
/usr/bin/ld: warning multiple definitions of symbol _locale_charset
../intl/libintl.a(localcharset.o) definition of _locale_charset in section
(__TEXT,__text)
/usr/lib/libiconv.dylib(localcharset.o) definition of _locale_charset
./xgcc -B./ -B/usr/i686-apple-darwin8.5.2/bin/ -isystem
/usr/i686-apple-darwin8.5.2/include -isystem
/usr/i686-apple-darwin8.5.2/sys-include
-L/Users/kraney/Desktop/gcc-3.4.5/gcc/../ld -DIN_GCC-W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -I. -I. -I. -I./. -I./../include -I../intl \
-c ./config/darwin-crt2.c -o crt2.o
./config/darwin-crt2.c: In function `__darwin_gcc3_preregister_frame_info':
./config/darwin-crt2.c:151: error: unrecognizable insn:
(insn 11 9 12 0 (set (reg/f:SI 58)
(plus:SI (reg:SI 3 bx)
(const:SI (minus:SI (symbol_ref:SI
("&L___keymgr_global$non_lazy_ptr"))
(symbol_ref:SI ("")) -1 (nil)
(nil))
./config/darwin-crt2.c:151: internal compiler error: in extract_insn, at
recog.c:2083
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [crt2.o] Error 1
make[1]: *** [stage1_build] Error 2
make: *** [bootstrap] Error 2
--
Summary: gcc 3.4.5 bootstrap fails w/ "unrecognizable insn" on
intel mac
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at junk dot kraney dot com
GCC host triplet: i686-apple-darwin8.5.2
GCC target triplet: i686-apple-darwin8.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26485
[Bug bootstrap/26485] gcc 3.4.5 bootstrap fails w/ "unrecognizable insn" on intel mac
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-27 17:21 --- As I mentioned in PR 26484, the port was fundamentally flawed in GCC before 4.0.x *** This bug has been marked as a duplicate of 26484 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26485
[Bug target/26484] GCC 3.4.5 fails to build on intel mac
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-27 17:21 --- *** Bug 26485 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26484
[Bug tree-optimization/26447] verify_flow_info failed
--- Comment #3 from aph at gcc dot gnu dot org 2006-02-27 17:22 --- I wouldn't expect to see such errors. Are you sure you used -findirect-dispatch ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26447
[Bug tree-optimization/26447] verify_flow_info failed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-27 17:23 --- Oh, I missed that, woops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26447
[Bug libgcj/26483] Wrong parsing of doubles when interpreted
--- Comment #3 from konqueror at gmx dot de 2006-02-27 17:26 --- I dont think so as the testcase works correctly on amd64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #28 from jakub at gcc dot gnu dot org 2006-02-27 17:26 --- Subject: Bug 26208 Author: jakub Date: Mon Feb 27 17:26:26 2006 New Revision: 111488 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111488 Log: PR other/26208 * unwind-dw2.c (struct _Unwind_Context): Add signal_frame field. (extract_cie_info): Handle S flag in augmentation string. (execute_cfa_program): If context->signal_frame, execute also fs->pc == context->ra instructions. (uw_frame_state_for): If context->signal_frame, don't subtract one from context->ra to find FDE. (uw_update_context_1): Set context->signal_frame to fs->signal_frame. (_Unwind_GetIPInfo): New function. * unwind-dw2.h (_Unwind_FrameState): Add signal_frame field. * unwind-c.c (PERSONALITY_FUNCTION): Use _Unwind_GetIPInfo instead of _Unwind_GetIP. * unwind-sjlj.c (_Unwind_GetIPInfo): New function. * unwind-generic.h (_Unwind_GetIPInfo): New prototype. * unwind-compat.c (_Unwind_GetIPInfo): New function. * libgcc-std.ver (_Unwind_GetIPInfo): Export @@GCC_4.2.0. * config/ia64/unwind-ia64.c (_Unwind_GetIPInfo): New function. * config/arm/unwind-arm.h (_Unwind_GetIPInfo): Define. * config/i386/linux-unwind.h (x86_fallback_frame_state, x86_64_fallback_frame_state): Set fs->signal_frame. * config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Likewise. (MD_FROB_UPDATE_CONTEXT): Define unconditionally. (frob_update_context): Likewise. Workaround missing S flag in Linux 2.6.12 - 2.6.16 kernel vDSOs. * config/s390/linux-unwind.h (s390_fallback_frame_state): Likewise. Remove the psw_addr + 1 hack. libjava/ * exception.cc (PERSONALITY_FUNCTION): Use _Unwind_GetIPInfo instead of _Unwind_GetIP. * include/i386-signal.h (MAKE_THROW_FRAME): Change into empty macro. (HANDLE_DIVIDE_OVERFLOW): Don't adjust _res->eip if falling through to throw. * include/x86_64-signal.h (MAKE_THROW_FRAME): Change into empty macro. * include/powerpc-signal.h (MAKE_THROW_FRAME): Change into empty macro. libstdc++-v3/ * libsupc++/eh_personality.cc (PERSONALITY_FUNCTION): Use _Unwind_GetIPInfo instead of _Unwind_GetIP. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/unwind-arm.h trunk/gcc/config/i386/linux-unwind.h trunk/gcc/config/ia64/unwind-ia64.c trunk/gcc/config/rs6000/linux-unwind.h trunk/gcc/config/s390/linux-unwind.h trunk/gcc/libgcc-std.ver trunk/gcc/unwind-c.c trunk/gcc/unwind-compat.c trunk/gcc/unwind-dw2.c trunk/gcc/unwind-dw2.h trunk/gcc/unwind-generic.h trunk/gcc/unwind-sjlj.c trunk/libjava/ChangeLog trunk/libjava/exception.cc trunk/libjava/include/i386-signal.h trunk/libjava/include/powerpc-signal.h trunk/libjava/include/x86_64-signal.h trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/eh_personality.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug tree-optimization/26447] [4.2 Regression] verify_flow_info failed, load PRE
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-27 17:32 --- Trying to get a reduced C++ testcase, load PRE is causing the ICE. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC target triplet|x86_64-unknown-linux-gnu|x86_64-linux-gnu Keywords||EH, ice-on-valid-code Summary|verify_flow_info failed |[4.2 Regression] ||verify_flow_info failed, ||load PRE Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26447
[Bug tree-optimization/26447] [4.2 Regression] verify_flow_info failed, load PRE
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-27 17:41 ---
This the best I can get but I never can get an ICE:
int f(int a, int *b, int *c, int *d)throw()
{
// try {
int e = *c;
if (e!=0)
*b = 1;
return *c+*d;
// } catch(...)
/* {
return 0;
}*/
}
Compile at -O2 -fnon-call-exceptions.
We do get:
# VUSE ;
D.2388_8 = *c_1;
pretmp.21_3 = D.2388_8;
Which looks wrong but I cannot get the ICE.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-02-27 17:41:37
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26447
[Bug other/26473] [4.1/4.2 Regression] cross-building installs ssp headers to $(includedir)
--- Comment #4 from ralf dot corsepius at rtems dot org 2006-02-27 17:44 --- (From update of attachment 10920) Though I still think GCC's toplevel configure to be bugged and this to be fixing some of then, this patch doesn't solve the problems of this PR. withdrawn -- ralf dot corsepius at rtems dot org changed: What|Removed |Added Attachment #10920|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26473
[Bug other/26473] [4.1/4.2 Regression] cross-building installs ssp headers to $(includedir)
--- Comment #5 from ralf dot corsepius at rtems dot org 2006-02-27 17:48 --- Created an attachment (id=10922) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10922&action=view) Move ssp headers into $(toolexeclibdir)/include This patch moves libssp's headers to $(toolexeclibdir)/include (/$version/include), similar to all other GCC internal headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26473
[Bug ada/14435] [3.4/4.0/4.1/4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics
--- Comment #21 from jason_gouger at mentor dot com 2006-02-27 18:11
---
Note / patch taken from duplicate bug 21553
--- Comment #5 From Jason 2005-09-20 02:17 [reply] ---
(In reply to comment #0)
> looking at gcc.c it looks like the problem is coming from the following line:
> gcc_libexec_prefix = make_relative_prefix
> (gcc_exec_prefix,
> standard_exec_prefix,
> standard_libexec_prefix);
>
> The problem is that make_relative_prefix is expecting a program name as first
> argument. But the gcc_exec_prefix is a directory. So that's why /my_prefix/ is
> removed when computing gcc_libexec_prefix...
I think there are more issues than that incorrect argument. From what I could
see was that even though make_relative_path expects a program name the return
path discards it which may be okay.
I am not sure on the original intent but preserving the common suffixes on arg2
and arg3 and then reapplying to the result seems to fix or at least work around
the problem.
>From make-relative-prefix.c :
For example, if @var{bin_prefix} is @code{/alpha/beta/gamma/gcc/delta},
@var{prefix} is @code{/alpha/beta/gamma/omega/}, and @var{progname} is
@code{/red/green/blue/gcc}, then this function will return
@code{/red/green/blue/../../omega/}.
progname = /red/green/blue/gcc
bin_prefix = /alpha/beta/gamma/gcc/delta
prefix = /alpha/beta/gamma/omega/
returns = /red/green/blue/../../omega/
In this case :
progname = /gcc-Y.Y.Y/lib/gcc (gcc_exec_prefix)
bin_prefix = /gcc-X.X.X/lib/gcc (standard_exec_prefix)
prefix = /gcc-X.X.X/libexec/gcc (standard_libexec_prefix)
returns = /gcc-Y.Y.Y/lib/../../libexec/gcc
1. make bin_prefix relative to prefix
/gcc-X.X.X/lib/gcc/../../libexec/gcc
2. Replace the program path '/gcc-X.X.X/lib' (dropped prg name gcc)
/gcc-Y.Y.Y/lib/../../libexec/gcc
So the ../.. is caused by the fact in step one make_relative_path needed to go
up two directories.
If we strip the common suffixes of bin_prefix and prefix and then reappend we
will get the desired result.
common_suffix=/gcc
progname = /gcc-Y.Y.Y/lib/gcc (gcc_exec_prefix)
bin_prefix = /gcc-X.X.X/lib (standard_exec_prefix w/out common
suffix)
prefix = /gcc-X.X.X/libexec (standard_libexec_prefix w/out common
suffix)
returns = /gcc-Y.Y.Y/lib/../libexec/gcc
1. make bin_prefix relative to prefix
/gcc-X.X.X/lib/../libexec
2. Replace the program path '/gcc-X.X.X/lib' (dropped prg name gcc)
/gcc-Y.Y.Y/lib/../libexec
3. Reappend common suffix
/gcc-Y.Y.Y/lib/../libexec/gcc
> Besides this I think that since 3.4.x series GCC_EXEC_PREFIX is quite useless
> indeed it is quite hard to redefine the location where cc1 is found
This worked properly in gcc 3.4.3 and prior releases.
To reproduce the problem install to a non-standard location. Remove (rename)
the build area. Rename the non-standard location to another non-standard name
and set the GCC_EXEC_PREFIX. In 3.4.3 this worked...
Here is a patch file against gcc 4.0.1 (gcc/gcc.c) which implements the
algorithm mentioned above.
3232,3235c
else
{
/* Find common ending of stanard_exec_prefix and standard_libexec_prefix.
// Essentially we are stripping /gcc/ for later use... This is required
// because make_relative path will just add ..'s for these directories.
// This is not the intention as the make_relative_path given three
// paths "progname", "bin_prefix", and "prefix"; returns the path that
// is in the same position relative to "progname's" directory as "prefix"
// is relative to "bin_prefix". So we can achieve the desired result by
// stripping this common suffix and concat'ing the result */
const char *exec_ptr = standard_exec_prefix + strlen
(standard_exec_prefix);
const char *libexec_ptr = standard_libexec_prefix + strlen
(standard_libexec_prefix);
char *exec_buf;
char *libexec_buf;
char *gccexec_buf;
int exec_len;
int libexec_len;
while (exec_ptr > standard_exec_prefix
&& libexec_ptr > standard_libexec_prefix
&& *exec_ptr == *libexec_ptr )
{
--exec_ptr;
--libexec_ptr;
}
if (exec_ptr > standard_exec_prefix)
++exec_ptr;
exec_len = exec_ptr - standard_exec_prefix;
exec_buf = xmalloc(exec_len + 1);
strncpy(exec_buf, standard_exec_prefix, exec_len);
exec_buf[exec_len] = '\0';
if (libexec_ptr > standard_libexec_prefix)
++libexec_ptr;
libexec_len = libexec_ptr - standard_libexec_prefix;
libexec_buf = xmalloc(libexec_len + 1);
strncpy(libexec_buf, standard_libexec_prefix, libexec_len);
libexec_buf[libexec_len] = '\0';
/* NOTE: make_relative_path really takes a program name as the
// first argument. However, even though it is a directory
// it just needs to be stripped. */
gccexec_buf = make_relative_prefix (gcc_exec_prefix,
exec_buf,
[Bug tree-optimization/26447] [4.2 Regression] verify_flow_info failed, load PRE
--- Comment #7 from dberlin at gcc dot gnu dot org 2006-02-27 19:45 --- Subject: Bug 26447 Give this patch a try and let me know if it works for you -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26447
[Bug tree-optimization/26447] [4.2 Regression] verify_flow_info failed, load PRE
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-02-27 19:46 --- Subject: Bug 26447 Whoops, forgot patch --- Comment #9 from dberlin at gcc dot gnu dot org 2006-02-27 19:46 --- Created an attachment (id=10923) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10923&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26447
[Bug rtl-optimization/25196] [4.0 Regression] i386: wrong arguments passed
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-02-27 20:17 --- Steven, would you please apply this patch ASAP? Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
[Bug c++/25632] [4.0 Regression] ICE with const int copied into two different functions
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-02-27 20:21 --- Zdenek, does your patch apply to 4.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25632
[Bug c/25682] [4.0 Regression] ICE when using old sytle offsetof (with non zero start) as array size
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-02-27 20:23 --- Jakub, does your patch apply to 4.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25682
[Bug c/25805] [3.4/4.0 Regression] Incorrect handling of zero-initialized flexible arrays
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-02-27 20:25 --- Marked as P2. This is a serious issue for those it affects, but it is indeed a corner case. Also, since this was broken from 3.3.x forwards, there is presumably relatively little code using the construct; certainly, for 4.0.x, this bug will not be preventing upgrades from previous 4.0.x releases. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25805
[Bug middle-end/19983] __builtin_nan should allow 0X as well as 0x
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-27 20:25 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19983
[Bug testsuite/25831] [4.0 only] FAIL: gcc.dg/20050922-1.c (test for excess errors)
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-02-27 20:26 --- This is just a testsuite issue; not release-critical. (It's OK to fix the bug, though, if someone wants to do that.) -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25831
[Bug target/25917] [4.0 Regression] gcc.c-torture/compile/20051228-1.c fails
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-02-27 20:27 --- IA64 is a secondary platform for GCC 4.0.x. As such, it's too bad this isn't fixed, but not release critical; P2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25917
[Bug middle-end/26092] [4.0 Regression] ICE on const function pointer assigned to a builtin function
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-02-27 20:29 --- Jakub, does this patch apply to 4.0.x? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26092
[Bug target/26098] [4.0 Regression] ICE in multiplication of 16-byte longlong vector on x86_64
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-02-27 20:29 --- Set to P2. This bug is somewhat exotic, and not a regression from previous 4.0.x releases. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26098
[Bug ada/26111] [4.0 Regression] Ada ICE in expand_assignment, at expr.c:3824
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-02-27 20:32 --- Ada is not release-critical; P5. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26111
[Bug fortran/25576] [4.0 only] checking failure in execute/intrinsic_eoshift.f90
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-02-27 20:33 --- Fortran is not release-critical; P5. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25576
[Bug debug/26475] tree-ssa loses line numbers for initializations
--- Comment #1 from drow at gcc dot gnu dot org 2006-02-27 20:44 --- Dan Berlin, Diego, and I bounced this around on IRC a little. A couple of things that came up: - Diego suggested putting locuses on unshared INTEGER_CSTs as another possible approach. - I suggested that if we want line numbers to be useful with optimization, we need to enforce and verify setting locuses. - Dan Berlin responded: I think then a start may be to propose that we require EXPR_LOCATIOn on every modify_expr to be non-null and verified by verify_stmts. That will break pretty much everywhere inserting code without locuses (which i know includes PRE :P) As we discover where we need to propagate more info around (phi args, wherever), we come up with a design for what needs to be done where. The only thing i know tries to keep line number info sane is tree-sra.c. Things like PRE should be using the line-number preserving sra_* functions (moved somewhere else and renamed bsi_*_with_location). Anyhoo, that's how i'd approach it. As you've said, there is no point in trying to put more information in places if we don't keep the basic stmt info up to date :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26475
[Bug rtl-optimization/25196] [4.0 Regression] i386: wrong arguments passed
--- Comment #12 from steven at gcc dot gnu dot org 2006-02-27 21:12 --- Subject: Bug 25196 Author: steven Date: Mon Feb 27 21:12:54 2006 New Revision: 111490 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111490 Log: Backport from mainline and the GCC 4.1 branch: PR rtl-optimization/25196 * postreload-gcse.c (record_last_set_info): Notice stack pointer changes in push insns without REG_INC notes. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr25196.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/postreload-gcse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
[Bug rtl-optimization/25196] [4.0 Regression] i386: wrong arguments passed
--- Comment #13 from steven at gcc dot gnu dot org 2006-02-27 21:13 --- 'tis done. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
[Bug libgcj/26487] New: Weird handling of HTTP Headers
When retrieving the headers from a URLConnection the results differ from what happens with the Sun jvm. Specifically some headers get mashed together instead of apearing as 2 different headers. I think this happens if a header with the same name appears twice (with different values). I will attach a test case. -- Summary: Weird handling of HTTP Headers Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ifoox at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26487
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #11 from steven at gcc dot gnu dot org 2006-02-27 21:42 --- Re. comment #3, testing all releases is, I'm sorry to say, rather worthless. Things usually break during development, not during the release process. Obviously nobody can tell you what to do with your resources, but it shouldn't be very hard for a company like FreeScale to set up an automatic testing system and test the trunk more regularly, instead of testing it days before a release and filing 11th hour bug reports. The fact that Mark would accept a patch for GCC 4.1.0 for this problem really surprises me. I'd use the opportunity and try to fix the problem asap ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug libgcj/26487] Weird handling of HTTP Headers
--- Comment #1 from ifoox at redhat dot com 2006-02-27 21:42 --- On further investigation it seems like the headers are represented similarly when they are recieved but URLConnection.getHeaderFieldKey and URLConnection.getHeaderField don't behave as expected. -- ifoox at redhat dot com changed: What|Removed |Added CC||ifoox at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26487
[Bug libgcj/26487] Weird handling of HTTP Headers
--- Comment #2 from ifoox at redhat dot com 2006-02-27 21:44 --- Created an attachment (id=10926) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10926&action=view) Test case Compile simply with 'TestLoginCookie.java' and run with 'java TestLoginCookie'. I'll also attach what I found from this test case next. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26487
[Bug libgcj/26487] Weird handling of HTTP Headers
--- Comment #3 from ifoox at redhat dot com 2006-02-27 21:47 ---
Here's what the output of URLConnection.getHeaderFields() is for GCJ:
{null=[HTTP/1.1 200 OK], Date=[Mon, 27 Feb 2006 21:34:40 GMT],
Server=[Apache/2.0.46 (Red Hat)], Set-Cookie=[Bugzilla_login=192617;
path=/bugzilla; expires=Fri, 01-Jan-2038 00:00:00 GMT,
Bugzilla_logincookie=653228; path=/bugzilla; expires=Fri, 01-Jan-2038 00:00:00
GMT], Keep-Alive=[timeout=15, max=100], Connection=[Keep-Alive],
Transfer-Encoding=[chunked], Content-Type=[text/html; charset=]}
Here's the output for Sun 1.5:
{Connection=[Keep-Alive], Set-Cookie=[Bugzilla_logincookie=653232;
path=/bugzilla; expires=Fri, 01-Jan-2038 00:00:00 GMT, Bugzilla_login=192617;
path=/bugzilla; expires=Fri, 01-Jan-2038 00:00:00 GMT], null=[HTTP/1.1 200 OK],
Date=[Mon, 27 Feb 2006 21:35:37 GMT], Keep-Alive=[timeout=15, max=100],
Server=[Apache/2.0.46 (Red Hat)], Content-Type=[text/html; charset=],
Transfer-Encoding=[chunked]}
These are the same, but when I loop through the headers and print them out
here's what GCJ produces:
null: 'HTTP/1.1 200 OK'
Date: 'Mon, 27 Feb 2006 21:34:40 GMT'
Server: 'Apache/2.0.46 (Red Hat)'
Set-Cookie: 'Bugzilla_login=192617; path=/bugzilla; expires=Fri,
01-Jan-2038 00:00:00 GMT, Bugzilla_logincookie=653228; path=/bugzilla;
expires=Fri, 01-Jan-2038 00:00:00 GMT'
Keep-Alive: 'timeout=15, max=100'
Connection: 'Keep-Alive'
Transfer-Encoding: 'chunked'
Content-Type: 'text/html; charset='
and here's Sun:
null: 'HTTP/1.1 200 OK'
Date: 'Mon, 27 Feb 2006 21:35:37 GMT'
Server: 'Apache/2.0.46 (Red Hat)'
Set-Cookie: 'Bugzilla_login=192617; path=/bugzilla; expires=Fri,
01-Jan-2038 00:00:00 GMT'
Set-Cookie: 'Bugzilla_logincookie=653232; path=/bugzilla; expires=Fri,
01-Jan-2038 00:00:00 GMT'
Keep-Alive: 'timeout=15, max=100'
Connection: 'Keep-Alive'
Transfer-Encoding: 'chunked'
Content-Type: 'text/html; charset='
So it seems like libgcj's version of these 2 functions considers the two
instances of Set-Cookie to be one header whereas Sun considers them to be 2
separate headers. IBM 1.4.1 shows them as 2 seperate headers, although it
returns an empty Map from URLConnection.getHeaderFields() for some reason.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26487
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- Comment #14 from quanah at stanford dot edu 2006-02-27 22:19 --- I've tried the patch suggested in this bug. However, I found that it does *not* fix all the issues. For example, here is the result of my libstdc++.la file with the patch applied: # Libraries that this one depends upon. dependency_libs=' -L/afs/ir/src/pubsw/languages/gcc-build/@sys/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/afs/ir/src/pubsw/languages/gcc-build/@sys/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -lm -lm -lm -L/afs/ir/src/pubsw/languages/gcc-build/@sys/gcc -L/usr/pubsw/lib/gcc/x86_64-unknown-linux-gnu/4.0.2 -L/usr/local/lib -L/usr/pubsw/lib -L/lib/../lib64 -L/usr/lib/../lib64 -lgcc_s -lc -lgcc_s -lm -lgcc_s -lc -lgcc_s' As you can see, there are still *three* references to the build location. Also, there are an amazing number of -lm's and -lgcc_s's that are unnecessary. What I expect this to look like is simply: dependency_libs=' -lm -L/usr/pubsw/lib -lgcc_s' because, quite frankly, that is all that is necessary. --Quanah -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
[Bug other/26473] [4.1/4.2 Regression] cross-building installs ssp headers to $(includedir)
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-02-27 22:29 --- Created an attachment (id=10927) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10927&action=view) Proposed patch -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Attachment #10922|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26473
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #12 from steven at gcc dot gnu dot org 2006-02-27 22:36 ---
With "GNU C version 4.1.0 20060222 (prerelease) (powerpc-unknown-linux-gnuspe)"
I get a different ICE:
$ ./cc1 -O2 -fno-inline t.c
foo
t.c: In function 'foo':
t.c:9: warning: incompatible implicit declaration of built-in function 'ldexp'
Analyzing compilation unitPerforming intraprocedural optimizations
Assembling functions:
foo
t.c: In function 'foo':
t.c:12: error: unrecognizable insn:
(insn 77 60 32 2 (set (subreg:DF (reg:DI 3 3 [128]) 0)
(mem/u/c/i:DF (reg/f:SI 9 9 [126]) [3 S8 A64])) -1 (nil)
(expr_list:REG_DEAD (reg/f:SI 9 9 [126])
(nil)))
t.c:12: internal compiler error: in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
$ cat t.c
void
foo (long exponent, double *to)
{
double dto;
dto = 0.0;
if (!exponent)
dto = ldexp (1.0, exponent);
*to = dto;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #13 from steven at gcc dot gnu dot org 2006-02-27 22:42 --- The insn triggering my ICE appears in peephole2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26481] ICE with -mcpu=power and struct passing
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-02-27 22:42 --- Retargeted at 4.1.1 per David's comments. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26481
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #14 from steven at gcc dot gnu dot org 2006-02-27 22:44 ---
Before peephole2:
(insn:HI 27 60 28 2 (set (reg:DF 0 0 [125])
(mem/u/c/i:DF (reg/f:SI 9 9 [126]) [3 S8 A64])) 892
{*movdf_e500_double} (insn_list:REG_DEP_TRUE 26 (nil))
(expr_list:REG_DEAD (reg/f:SI 9 9 [126])
(expr_list:REG_EQUIV (const_double:DF 1.0e+0 [0x0.8p+1])
(nil
(insn:HI 28 27 32 2 (set (subreg:DF (reg:DI 3 3 [128]) 0)
(reg:DF 0 0 [125])) 889 {*frob_di_df_2} (insn_list:REG_DEP_TRUE 27
(nil))
(expr_list:REG_DEAD (reg:DF 0 0 [125])
(nil)))
After peephole2:
(insn 77 60 32 2 (set (subreg:DF (reg:DI 3 3 [128]) 0)
(mem/u/c/i:DF (reg/f:SI 9 9 [126]) [3 S8 A64])) -1 (nil)
(expr_list:REG_DEAD (reg/f:SI 9 9 [126])
(nil)))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug c++/26489] New: compilation of c++ fails in eh_alloc.cc on NetBSD
With a freshly svn up'ed gcc to the 4.1.0 branch, and an empty obj dir, I get the following compile error on NetBSD-current (3.99.15). /aux/obj/gcc41/./gcc/xgcc -shared-libgcc -B/aux/obj/gcc41/./gcc -nostdinc++ -L/a ux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/src -L/aux/obj/gcc41/i38 6-unknown-netbsdelf3.99.15/libstdc++-v3/src/.libs -B/usr/local//i386-unknown-net bsdelf3.99.15/bin/ -B/usr/local//i386-unknown-netbsdelf3.99.15/lib/ -isystem /usr/local//i386-unknown-netbsdelf3.99.15/include -isystem /usr/local//i386-unknown-netbsdelf3.99.15/sys-include -I/aux/src/gcc41/libstdc++-v3/../gcc -I/aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15 -I/aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include -I/aux/src/gcc41/libstdc++-v3/libsupc++ -g -O2 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c /aux/src/gcc41/libstdc++-v3/libsupc++/eh_alloc.cc -fPIC -DPIC -o eh_alloc.o /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h: In function 'int __gthread_once(__gthread_once_t*, void (*)())': /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h:515: error: '__gthrw_pthread_once' was not declared in this scope /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h: In function 'int __gthread_key_create(__gthread_key_t*, void (*)(void*))': /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h:523: error: '__gthrw_pthread_key_create' was not declared in this scope /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h: In function 'int __gthread_key_delete(__gthread_key_t)': /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h:529: error: '__gthrw_pthread_key_delete' was not declared in this scope /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h: In function 'void* __gthread_getspecific(__gthread_key_t)': /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h:535: error: '__gthrw_pthread_getspecific' was not declared in this scope /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h: In function 'int __gthread_setspecific(__gthread_key_t, const void*)': /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h:541: error: '__gthrw_pthread_setspecific' was not declared in this scope /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h: In function 'int __gthread_mutex_lock(__gthread_mutex_t*)': /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-n etbsdelf3.99.15/bits/gthr-default.h:548: error: '__gthrw_pthread_mutex_lock' was not declared in this scope /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h: In function 'int __gthread_mutex_trylock(__gthread_mutex_t*)': /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h:557: error: '__gthrw_pthread_mutex_trylock' was not declared in this scope /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h: In function 'int __gthread_mutex_unlock(__gthread_mutex_t*)': /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h:566: error: '__gthrw_pthread_mutex_unlock' was not declared in this scope /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h: In function 'int __gthread_recursive_mutex_init_function(__gthread_recursive_mutex_t*)': /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h:580: error: '__gthrw_pthread_mutexattr_init' was not declared in this scope /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h:582: error: '__gthrw_pthread_mutexattr_settype' was not declared in this scope /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h:584: error: '__gthrw_pthread_mutex_init' was not declared in this scope /aux/obj/gcc41/i386-unknown-netbsdelf3.99.15/libstdc++-v3/include/i386-unknown-netbsdelf3.99.15/bits/gthr-default.h:586: error: '__gthrw_pthread_mutexattr_destroy' was not declared in this scope It looks like this might be attri
[Bug libstdc++/26489] [4.1/4.2 Regression] compilation of c++ fails in eh_alloc.cc on NetBSD
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c++ |libstdc++ Keywords||build Summary|compilation of c++ fails in |[4.1/4.2 Regression] |eh_alloc.cc on NetBSD |compilation of c++ fails in ||eh_alloc.cc on NetBSD Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26489
[Bug c/26490] New: tree check fail on valid C code
I just tried to compile Suse Linux package graphviz-2.6-9 with a recent GNU C++ compiler version 4.2 snapshot 20060225. The compiler snapshot said ~dcb/gnu/42-20060225/results/bin/gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../lib/common -I../../lib/gvc -I../../lib/pack -I../../lib/pathplan -I../../lib/graph -I../../lib/cdt -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -W -Wall -Wno-unused-parameter -Wno-unknown-pragmas -Wstrict-prototypes -Wpointer-arith -ffast-math -Wno-unused-parameter -Wno-unknown-pragmas -Wstrict-prototypes -c adjust.c -fPIC -DPIC adjust.c: In function "countOverlap": adjust.c:317: internal compiler error: tree check: expected ssa_name, have type_memory_tag in verify_ssa, at tree-ssa.c:735 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. -O2 Flags required. -- Summary: tree check fail on valid C code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26490
[Bug c/26490] tree check fail on valid C code
--- Comment #1 from dcb314 at hotmail dot com 2006-02-27 23:10 --- Created an attachment (id=10928) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10928&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26490
[Bug tree-optimization/26490] tree check fail on valid C code
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-27 23:18 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26490
[Bug fortran/26393] ICE with function returning variable lenght array
--- Comment #4 from patchapp at dberlin dot org 2006-02-27 23:30 --- Subject: Bug number PR26393 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02025.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26393
[Bug rtl-optimization/17387] Redundant instructions in loop optimization
--- Comment #19 from hjl at lucon dot org 2006-02-27 23:40 ---
Even with the new patch
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01994.html
I still got the same result. The new see pass won't touch
(insn:HI 13 9 14 2 (set (reg/v:SI 73 [ t ])
(mem/s:SI (symbol_ref:DI ("state") [flags 0x40] ) [3 state+0 S4 A32])) 40 {*movsi_1} (nil)
(nil))
(insn:HI 14 13 16 2 (parallel [
(set (reg/v:SI 73 [ t ])
(xor:SI (mem/s:SI (symbol_ref:DI ("S") [flags 0x40] ) [3 S+0 S4 A32])
(reg/v:SI 73 [ t ])))
(clobber (reg:CC 17 flags))
]) 340 {*xorsi_1} (insn_list:REG_DEP_TRUE 13 (nil))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (xor:SI (mem/s:SI (symbol_ref:DI ("S") [flags
0x40] ) [3 S+0 S4 A32])
(mem/s:SI (symbol_ref:DI ("state") [flags 0x40] ) [3 state+0 S4 A32]))
(nil
(insn:HI 16 14 18 2 (set (mem/s:SI (symbol_ref:DI ("state") [flags 0x40]
) [3 state+0 S4 A32])
(reg/v:SI 73 [ t ])) 40 {*movsi_1} (insn_list:REG_DEP_TRUE 14 (nil))
(nil))
(insn:HI 18 16 21 2 (set (reg:DI 79 [ t ])
(zero_extend:DI (reg/v:SI 73 [ t ]))) 111 {zero_extendsidi2_rex64}
(nil)
(expr_list:REG_DEAD (reg/v:SI 73 [ t ])
(nil)))
--
hjl at lucon dot org changed:
What|Removed |Added
Version|4.0.0 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
[Bug libstdc++/26489] [4.1/4.2 Regression] compilation of c++ fails in eh_alloc.cc on NetBSD
--- Comment #1 from dogcow at babymeat dot com 2006-02-27 23:55 --- And, in fact, reverting gthr-posix.h to -r 110280 makes things build successfully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26489
[Bug tree-optimization/26490] [4.2 Regression] tree check fail on valid C code
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-28 00:08 ---
Reduced testcase:
extern int nsites;
typedef struct Site {
} Site;
typedef struct ptitem {
Site site;
int overlaps;
} Info_t;
extern Info_t *nodeInfo;
int countOverlap(int iter)
{
int i, j;
Info_t *ip = nodeInfo;
Info_t *jp;
for (i = 0; i < nsites - 1; i++)
{
jp = ip + 1;
if (polyOverlap (ip->site))
jp->overlaps = 1;
ip++;
}
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-02-28 00:08:28
date||
Summary|tree check fail on valid C |[4.2 Regression] tree check
|code|fail on valid C code
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26490
[Bug c++/25632] [4.0 Regression] ICE with const int copied into two different functions
--- Comment #18 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-02-28 00:18 --- Subject: Re: [4.0 Regression] ICE with const int copied into two different functions > Zdenek, does your patch apply to 4.0? yes, it does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25632
[Bug fortran/26491] New: Internal compiler error
/usr/local/gcc42/bin/gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c,c++,fortran --prefix=/usr/local/gcc42 --disable-bootstrap Thread model: posix gcc version 4.2.0 20060225 (experimental) f90 source file (24.f90 on mu local system is module S publicp interface p module procedure p end interface contains subroutine p() character(128) :: word call redirect_((/word/)) end subroutine end command line is /usr/local/gcc42/bin/gfortran -O0 -S 24.f90 error output is 24.f90: In function p: 24.f90:9: internal compiler error: in gimplify_expr, at gimplify.c:5788 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. gfortran built from source snapshot 20060225 on x86_64 system using SuSE linux 10.0 Bug is major/critical to me because the source is from one of the SPEC CPU2006 candidates and I believe it would be useful if gfortran could run this suite. -- Summary: Internal compiler error Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot paton at amd dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26491
