[Bug target/6221] mips-irix6 gcc-3.1 testsuite failure in gcc.c-torture/execute/20020227-1.c
--- Additional Comments From rth at gcc dot gnu dot org 2004-11-24 08:21 --- Mine. -- What|Removed |Added AssignedTo|echristo at redhat dot com |rth at redhat dot com Status|SUSPENDED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6221
[Bug target/6221] mips-irix6 gcc-3.1 testsuite failure in gcc.c-torture/execute/20020227-1.c
--- Additional Comments From rth at gcc dot gnu dot org 2004-11-24 08:23 --- May be fixed by 2004-11-23 Richard Henderson [EMAIL PROTECTED] * expmed.c (extract_bit_field): Use simplify_gen_subreg instead of hard-coding avoiding calls to gen_rtx_SUBREG. Split complex return modes to CONCAT. -- What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6221
[Bug target/16800] PowerPC - Unnecessary rldicl
--- Additional Comments From amodra at bigpond dot net dot au 2004-11-24 09:40 --- Of course, fixing the odd rtx_cost for the (const_int 0) inside an EQ doesn't help this particular bug. More or less the same happens: rejecting combination of insns 21 and 22 original costs 4 + 4 = 8 replacement cost 12 It's the 12 counted for EQ that's the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16800
[Bug target/6221] mips-irix6 gcc-3.1 testsuite failure in gcc.c-torture/execute/20020227-1.c
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-24 09:46 --- May be fixed by 2004-11-23 Richard Henderson [EMAIL PROTECTED] * expmed.c (extract_bit_field): Use simplify_gen_subreg instead of hard-coding avoiding calls to gen_rtx_SUBREG. Split complex return modes to CONCAT. Confirmed on SPARC 64-bit: XPASS: gcc.c-torture/execute/20020227-1.c execution, -O2 XPASS: gcc.c-torture/execute/20020227-1.c execution, -Os -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6221
[Bug target/18630] can't find a register in class `GENERAL_REGS' when trying to make Firefox 1.0
--- Additional Comments From Dirk dot Schwartzkopff at gmx dot de 2004-11-24 10:01 --- Created an attachment (id=7593) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7593action=view) Missing *.i* file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
[Bug target/18630] can't find a register in class `GENERAL_REGS' when trying to make Firefox 1.0
--- Additional Comments From Dirk dot Schwartzkopff at gmx dot de 2004-11-24 10:03 --- Created an attachment (id=7594) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7594action=view) Missing *.i* file with type text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
[Bug c++/18470] [4.0 regression] array bound rejected as non-constant in template
--- Additional Comments From giovannibajo at libero dot it 2004-11-24 10:05 --- Yes, Mark, but it used to work just a few weeks ago, and it is a rejects-valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18470
[Bug target/18630] can't find a register in class `GENERAL_REGS' when trying to make Firefox 1.0
--- Additional Comments From giovannibajo at libero dot it 2004-11-24 10:07 --- Ulrich, you may want to have a look at this. -- What|Removed |Added CC||uweigand at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
[Bug c++/16882] [4.0 Regression] overloading confused by const vector arguments
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-24 10:07 --- Subject: Bug 16882 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-24 10:06:55 Modified files: gcc: ChangeLog tree.c gcc/cp : ChangeLog call.c typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/conversion: simd1.C Log message: 2004-11-24 Paolo Bonzini [EMAIL PROTECTED] PR c++/16882 * tree.c (make_vector_type): Move qualifiers to the vector type, use the inner type's main variant and build a main variant for the vector type if necessary. (type_hash_eq): Check a vector type's TYPE_VECTOR_SUBPARTS. cp: 2004-11-24 Paolo Bonzini [EMAIL PROTECTED] PR c++/16882 * call.c (standard_conversion): Move check for conversions between vector pointers... * typeck.c (ptr_reasonably_similar): ... here. testsuite: 2004-11-24 Paolo Bonzini [EMAIL PROTECTED] PR c++/16882 * g++.dg/conversion/simd1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6507r2=2.6508 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gccr1=1.449r2=1.450 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4488r2=1.4489 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gccr1=1.519r2=1.520 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gccr1=1.597r2=1.598 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4636r2=1.4637 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/conversion/simd1.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16882
[Bug c++/8929] gcc accepts illegal specialization syntax
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-24 10:40 --- Subject: Bug 8929 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-24 10:40:16 Modified files: gcc/cp : ChangeLog decl.c gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.oliva: template10.C Log message: PR c++/8929 * decl.c (start_decl): Check for invalid specialization headers. PR c++/8929 * g++.old-deja/g++.oliva/template10.C: Remove xfail. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4489r2=1.4490 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1329r2=1.1330 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4638r2=1.4639 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.oliva/template10.C.diff?cvsroot=gccr1=1.3r2=1.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8929
[Bug c++/8929] G++ accepts invalid template headers in member definitions of explicitly specialized classes
--- Additional Comments From giovannibajo at libero dot it 2004-11-24 10:41 --- Fixed for GCC 4.0.0. Thanks Martin for your report! -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|gcc accepts illegal |G++ accepts invalid template |specialization syntax |headers in member ||definitions of explicitly ||specialized classes Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8929
[Bug middle-end/18499] [4.0 Regression] quadratic behavior in cfgexpand
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-24 11:12 --- (From update of attachment 7547) The problem was searching edges the edge-dest block in remove_edge, but we now have dest_idx on for edge (thanks to Kazu's O(1) PHI arg lookup patches) so we don't have to search the dest block anymore. So I suspect at least the part of the problem that put remove_edge high up in the profile is now fixed, and my patch is obsolete. I'll reprofile and see what else we can do to speed up this test case... -- What|Removed |Added Attachment #7547 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18499
[Bug tree-optimization/18595] IV-OPTS is slow (and does not scale)
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-24 11:14 --- if IV opts doesn't scale, then why is the compile time ~14% in both cases? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18595
[Bug tree-optimization/18594] PHI insertion is slow
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-24 11:16 --- I think part of the problem is that PHI insertion is just not a linear algorithm (iirc it's Nlog(N)). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-24 11:16:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18594
[Bug c++/18192] Serious Performance Bug depending on a donothing destructor declaration
-- What|Removed |Added GCC host triplet|SuSE 9.0|SuSE 9.2 Version|3.4.2 |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18192
[Bug c++/16882] [4.0 Regression] overloading confused by const vector arguments
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 12:46 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16882
[Bug c/18645] New: Impossible to built gcc 3.4.3 with gcc 3.2.2; missing crti.o; no *.i* files available
/mnt/gcc-3.4.3/gcc /mnt/gcc-3.4.3/gcc/xgcc -B/mnt/gcc-3.4.3/gcc/ -B/usr/local/s390x-ibm-linux/bin/ -B/usr/local/s390x-ibm-linux/lib/ -isystem /usr/local/s390x-ibm-linux/include -isystem /usr/local/s390x-ibm-linux/sys-include -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -save-temps -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/32/libgcc.map -o 32/libgcc_s.so.1.tmp -m31 libgcc/32/_muldi3.o libgcc/32/_negdi2.o libgcc/32/_lshrdi3.o libgcc/32/_ashldi3.o libgcc/32/_ashrdi3.o libgcc/32/_cmpdi2.o libgcc/32/_ucmpdi2.o libgcc/32/_floatdidf.o libgcc/32/_floatdisf.o libgcc/32/_fixunsdfsi.o libgcc/32/_fixunssfsi.o libgcc/32/_fixunsdfdi.o libgcc/32/_fixdfdi.o libgcc/32/_fixunssfdi.o libgcc/32/_fixsfdi.o libgcc/32/_fixxfdi.o libgcc/32/_fixunsxfdi.o libgcc/32/_floatdixf.o libgcc/32/_fixunsxfsi.o libgcc/32/_fixtfdi.o libgcc/32/_fixunstfdi.o libgcc/32/_floatditf.o libgcc/32/_clear_cache.o libgcc/32/_enable_execute_stack.o libgcc/32/_trampoline.o libgcc/32/__main.o libgcc/32/_absvsi2.o libgcc/32/_absvdi2.o libgcc/32/_addvsi3.o libgcc/32/_addvdi3.o libgcc/32/_subvsi3.o libgcc/32/_subvdi3.o libgcc/32/_mulvsi3.o libgcc/32/_mulvdi3.o libgcc/32/_negvsi2.o libgcc/32/_negvdi2.o libgcc/32/_ctors.o libgcc/32/_ffssi2.o libgcc/32/_ffsdi2.o libgcc/32/_clz.o libgcc/32/_clzsi2.o libgcc/32/_clzdi2.o libgcc/32/_ctzsi2.o libgcc/32/_ctzdi2.o libgcc/32/_popcount_tab.o libgcc/32/_popcountsi2.o libgcc/32/_popcountdi2.o libgcc/32/_paritysi2.o libgcc/32/_paritydi2.o libgcc/32/_divdi3.o libgcc/32/_moddi3.o libgcc/32/_udivdi3.o libgcc/32/_umoddi3.o libgcc/32/_udiv_w_sdiv.o libgcc/32/_udivmoddi4.o libgcc/32/unwind-dw2.o libgcc/32/unwind-dw2-fde-glibc.o libgcc/32/unwind-sjlj.o libgcc/32/gthr-gnat.o libgcc/32/unwind-c.o -lc rm -f libgcc_s_32.so if [ -f 32/libgcc_s.so.1 ]; then mv -f 32/libgcc_s.so.1 32/libgcc_s.so.1.`basename `; else true; fi mv 32/libgcc_s.so.1.tmp 32/libgcc_s.so.1 ln -s 32/libgcc_s.so.1 libgcc_s_32.so /usr/bin/ld: cannot open crti.o: Datei oder Verzeichnis nicht gefunden collect2: ld returned 1 exit status -- Summary: Impossible to built gcc 3.4.3 with gcc 3.2.2; missing crti.o; no *.i* files available Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Dirk dot Schwartzkopff at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: s390-*-linux-gnu GCC host triplet: s390-*-linux-gnu GCC target triplet: s390-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18645
[Bug target/18630] can't find a register in class `GENERAL_REGS' when trying to make Firefox 1.0
--- Additional Comments From Dirk dot Schwartzkopff at gmx dot de 2004-11-24 13:00 --- (In reply to comment #1) Please read http://gcc.gnu.org/bugs.html and attach the preprocessed source. Also please try a new gcc since 3.2.2 is getting old and 3.3.5 and 3.4.3 are out? Is is impossible to built 3.4.3, see Bug 18645. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
[Bug bootstrap/18645] Impossible to built gcc 3.4.3 with gcc 3.2.2; missing crti.o; no *.i* files available
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 13:01 --- Can you provide how you configured gcc? -- What|Removed |Added Component|c |bootstrap Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18645
[Bug other/16953] failure to build gcc-3.4.1 on IBM-AIX
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 13:04 --- Not a bug by comment #3. You need to first set CC to cc (as mentioned in the web page) and then configure and bootstrap and install and it will work. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16953
[Bug c/18646] New: Impossible to built gcc 3.4.3 with gcc 3.2.2; missing crti.o; no *.i* files available
/mnt/gcc-3.4.3/gcc /mnt/gcc-3.4.3/gcc/xgcc -B/mnt/gcc-3.4.3/gcc/ -B/usr/local/s390x-ibm-linux/bin/ -B/usr/local/s390x-ibm-linux/lib/ -isystem /usr/local/s390x-ibm-linux/include -isystem /usr/local/s390x-ibm-linux/sys-include -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -save-temps -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/32/libgcc.map -o 32/libgcc_s.so.1.tmp -m31 libgcc/32/_muldi3.o libgcc/32/_negdi2.o libgcc/32/_lshrdi3.o libgcc/32/_ashldi3.o libgcc/32/_ashrdi3.o libgcc/32/_cmpdi2.o libgcc/32/_ucmpdi2.o libgcc/32/_floatdidf.o libgcc/32/_floatdisf.o libgcc/32/_fixunsdfsi.o libgcc/32/_fixunssfsi.o libgcc/32/_fixunsdfdi.o libgcc/32/_fixdfdi.o libgcc/32/_fixunssfdi.o libgcc/32/_fixsfdi.o libgcc/32/_fixxfdi.o libgcc/32/_fixunsxfdi.o libgcc/32/_floatdixf.o libgcc/32/_fixunsxfsi.o libgcc/32/_fixtfdi.o libgcc/32/_fixunstfdi.o libgcc/32/_floatditf.o libgcc/32/_clear_cache.o libgcc/32/_enable_execute_stack.o libgcc/32/_trampoline.o libgcc/32/__main.o libgcc/32/_absvsi2.o libgcc/32/_absvdi2.o libgcc/32/_addvsi3.o libgcc/32/_addvdi3.o libgcc/32/_subvsi3.o libgcc/32/_subvdi3.o libgcc/32/_mulvsi3.o libgcc/32/_mulvdi3.o libgcc/32/_negvsi2.o libgcc/32/_negvdi2.o libgcc/32/_ctors.o libgcc/32/_ffssi2.o libgcc/32/_ffsdi2.o libgcc/32/_clz.o libgcc/32/_clzsi2.o libgcc/32/_clzdi2.o libgcc/32/_ctzsi2.o libgcc/32/_ctzdi2.o libgcc/32/_popcount_tab.o libgcc/32/_popcountsi2.o libgcc/32/_popcountdi2.o libgcc/32/_paritysi2.o libgcc/32/_paritydi2.o libgcc/32/_divdi3.o libgcc/32/_moddi3.o libgcc/32/_udivdi3.o libgcc/32/_umoddi3.o libgcc/32/_udiv_w_sdiv.o libgcc/32/_udivmoddi4.o libgcc/32/unwind-dw2.o libgcc/32/unwind-dw2-fde-glibc.o libgcc/32/unwind-sjlj.o libgcc/32/gthr-gnat.o libgcc/32/unwind-c.o -lc rm -f libgcc_s_32.so if [ -f 32/libgcc_s.so.1 ]; then mv -f 32/libgcc_s.so.1 32/libgcc_s.so.1.`basename `; else true; fi mv 32/libgcc_s.so.1.tmp 32/libgcc_s.so.1 ln -s 32/libgcc_s.so.1 libgcc_s_32.so /usr/bin/ld: cannot open crti.o: Datei oder Verzeichnis nicht gefunden collect2: ld returned 1 exit status -- Summary: Impossible to built gcc 3.4.3 with gcc 3.2.2; missing crti.o; no *.i* files available Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Dirk dot Schwartzkopff at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: s390-*-linux-gnu GCC host triplet: s390-*-linux-gnu GCC target triplet: s390-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18646
[Bug bootstrap/18645] Impossible to built gcc 3.4.3 with gcc 3.2.2; missing crti.o; no *.i* files available
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-11-24 13:11 --- You are apparently trying to build a bi-arch s390x-ibm-linux compiler; this is possible only if you have *both* 64-bit and 31-bit libc developement packages (including crt*.o) available. You'll need to either provide a 31-bit libc development pacakge, or else configure gcc with --disable-multilib to build a pure 64-bit compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18645
[Bug c/18646] Impossible to built gcc 3.4.3 with gcc 3.2.2; missing crti.o; no *.i* files available
--- Additional Comments From Dirk dot Schwartzkopff at gmx dot de 2004-11-24 13:12 --- *** This bug has been marked as a duplicate of 18645 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18646
[Bug bootstrap/18645] Impossible to built gcc 3.4.3 with gcc 3.2.2; missing crti.o; no *.i* files available
--- Additional Comments From Dirk dot Schwartzkopff at gmx dot de 2004-11-24 13:12 --- *** Bug 18646 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18645
[Bug target/18630] can't find a register in class `GENERAL_REGS' when trying to make Firefox 1.0
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-11-24 13:27 --- The inline assembly statement is impossible to reload under the given circumstances. Note that the statement requires 12 general purpose registers at the same time (6 inputs and 6 clobbers), but using the options you give, GCC 3.2 has only 11 general purpose registers available for general use (namely %r0 .. %r10; %r11 is the frame pointer, %r12 the GOT pointer, %r13 the literal pool pointer, %r14 the return address register and %r15 the stack pointer). You could either - rewrite the assembly to require one fewer register - build with -O (or -fomit-frame-pointer) to free up %r11 - build without -fPIC to free up %r12 (probably impossible) - use GCC 3.4 (as this makes %r14 available for general use) I'd recommend to simply use -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
[Bug bootstrap/18645] Impossible to built gcc 3.4.3 with gcc 3.2.2; missing crti.o; no *.i* files available
-- What|Removed |Added CC||uweigand at de dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18645
[Bug bootstrap/18645] Impossible to built gcc 3.4.3 with gcc 3.2.2; missing crti.o; no *.i* files available
-- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18645
[Bug c/18647] New: Internal compiler error: in ?, at insn-attrtab.c:1096
An internal compiler error when compiling the pdftex package. The details are: 1. GCC Version Reading specs from /home/bitmap/local/lib/gcc/hppa64-hp-hpux11.11/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/home/bitmap/local --enable- languages=c,c++ --with-gnu-as --with-gnu-ld Thread model: single gcc version 3.4.3 2. Compiler and Compiler options: aCC -Ae +DA2.0W 3. System info HP-UX porsx008 B.11.11 U 9000/800 2647643434 unlimited-user license 4. Command line that triggers the bug gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -c dvicopy.c -o dvicopy.o 5. The compiler output dvicopy.c: In function `pcktspair': dvicopy.c:869: error: unrecognizable insn: (insn 112 111 114 dvicopy.c:869 (use (reg/i:DI 28 %r28 [ result ])) -1 (insn_list 76 (nil)) (nil)) dvicopy.c:869: internal compiler error: in ?, at insn-attrtab.c:1096 -- Summary: Internal compiler error: in ?, at insn-attrtab.c:1096 Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rjf at netcabo dot pt CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18647
[Bug target/18630] can't find a register in class `GENERAL_REGS' when trying to make Firefox 1.0
-- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
[Bug preprocessor/15824] [4.0 Regression] uchar redefinition warnings in libcpp
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-24 14:01 --- Subject: Bug 15824 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-24 14:00:43 Modified files: libcpp : ChangeLog configure.ac configure Log message: PR preprocessor/15824 * configure.ac: Correct HAVE_UCHAR test to #include sys/types.h directly, instead of the non-existant system.h and ansidecl.h. * configure: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gccr1=1.40r2=1.41 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/configure.ac.diff?cvsroot=gccr1=1.9r2=1.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/configure.diff?cvsroot=gccr1=1.10r2=1.11 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15824
[Bug c/18647] Internal compiler error: in ?, at insn-attrtab.c:1096
--- Additional Comments From rjf at netcabo dot pt 2004-11-24 14:03 --- Created an attachment (id=7595) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7595action=view) The preprocessed file that triggers the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18647
[Bug c/18647] Internal compiler error: in ?, at insn-attrtab.c:1096
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 14:06 --- This is a dup of bug 14838, which is fixed in either 3.3.6 or 3.4.4 or the mainline, which neither of these have been released yet. *** This bug has been marked as a duplicate of 14838 *** *** This bug has been marked as a duplicate of 14838 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18647
[Bug rtl-optimization/14838] [3.3/3.4/4.0 Regression] ICE when building with -O2 -g
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 14:06 --- *** Bug 18647 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||rjf at netcabo dot pt http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14838
[Bug preprocessor/15824] [4.0 Regression] uchar redefinition warnings in libcpp
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 14:07 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15824
[Bug target/10901] [ppc-darwin] non-local goto's (still) don't work
--- Additional Comments From gcc at microbizz dot nl 2004-11-24 14:18 --- Subject: Re: [ppc-darwin] non-local goto's (still) don't work Q: What does a Software Project do with Bugs ? A: They Store Them in a Bug Database. Problem Solved ! Q: What does a Software Project do with Bugs That Are Not Welcome ? A: They Store Them in a Bug Database and then Assign Them Low Priority. This is Very Convenient because The Next Release will only target High Priority Bugs. Problem Solved ! Q: What does a Software Project do with Bugs After A Long Period, say 100 years ? A: The Bugs will Be Removed from the Bug Database, as Nobody has Cared About Them Anyway. Problem Solved ! Mr. Cynical -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901
[Bug rtl-optimization/18614] [3.4 Regression] ICE in simplify_binary_operation
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-24 14:21 --- Subject: Bug 18614 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-11-24 14:20:57 Modified files: gcc: ChangeLog simplify-rtx.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: pr18614-1.c Log message: PR rtl-optimization/18614 * simplify-rtx.c (simplify_binary_operation): Do not simplify inner elements of constant arguments of VEC_CONCAT insn. testsuite: * gcc.dg/pr18614-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.701r2=2.2326.2.702 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/simplify-rtx.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.172.4.3r2=1.172.4.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.311r2=1.3389.2.312 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr18614-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18614
[Bug rtl-optimization/18614] [3.4 Regression] ICE in simplify_binary_operation
--- Additional Comments From uros at gcc dot gnu dot org 2004-11-24 14:22 --- Fixed on 3.4 branch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18614
[Bug libgcj/18222] [4.0 Regression] libjava bootstrap failure on Tru64 UNIX: CPPFLAGS changed in libltdl
--- Additional Comments From ro at techfak dot uni-bielefeld dot de 2004-11-24 14:24 --- Subject: Re: [4.0 Regression] libjava bootstrap failure on Tru64 UNIX: CPPFLAGS changed in libltdl tromey at gcc dot gnu dot org writes: Perhaps it is a ksh quoting bug. Or perhaps my approach to reproducing it is incorrect somehow. To make sure the problem isn't shell dependent, I ran a bootstrap on alpha-dec-osf5.1b with CONFIG_SHELL set to bash: the same problem occured as with /bin/ksh. It would be worth digging through your config.status and config.cache files to see where the extra space occurs and where it does not. This will help in isolating the bug, e.g. if the space is in config.status then the bug probably occurs during the actual invocation; if the space is in config.cache but not config.status then it may be stripped when creating config.status, etc. In the alpha-dec-osf5.1b build mentioned above, I find in alpha-dec-osf5.1b/libjava/config.cache: ac_cv_env_CPPFLAGS_value='-O2 -g -O2 -mieee' i.e. the extra space occurs. In config.status, there is with options \'--cache-file=./config.cache' '--host=alpha-dec-osf5.1b' '--build=alpha-dec-osf5.1b' '--enable-multilib' '--prefix=/vol/gcc' '--with-local-prefix=/vol/gcc' '--disable-nls' '--disable-libmudflap' '--with-gcc-version-trigger=/vol/gnu/src/gcc/gcc-dist/gcc/version.c' '--enable-languages=c,c++,java,objc' '--program-transform-name=s,y,y,' '--srcdir=/vol/gnu/src/gcc/gcc-dist/libjava' '--with-target-subdir=alpha-dec-osf5.1b' 'CPPFLAGS=-O2 -g -O2 -mieee' 'build_alias=alpha-dec-osf5.1b' 'host_alias=alpha-dec-osf5.1b' 'target_alias=alpha-dec-osf5.1b' --enable-ltdl-convenience --with-auxdir=/vol/gnu/src/gcc/gcc-dist\ echo running /usr/local/bin/bash /vol/gnu/src/gcc/gcc-dist/libjava/configure '--cache-file=./config.cache' '--host=alpha-dec-osf5.1b' '--build=alpha-dec-osf5.1b' '--enable-multilib' '--prefix=/vol/gcc' '--with-local-prefix=/vol/gcc' '--disable-nls' '--disable-libmudflap' '--with-gcc-version-trigger=/vol/gnu/src/gcc/gcc-dist/gcc/version.c' '--enable-languages=c,c++,java,objc' '--program-transform-name=s,y,y,' '--srcdir=/vol/gnu/src/gcc/gcc-dist/libjava' '--with-target-subdir=alpha-dec-osf5.1b' 'CPPFLAGS=-O2 -g -O2 -mieee' 'build_alias=alpha-dec-osf5.1b' 'host_alias=alpha-dec-osf5.1b' 'target_alias=alpha-dec-osf5.1b' --enable-ltdl-convenience --with-auxdir=/vol/gnu/src/gcc/gcc-dist $ac_configure_extra_args --no-create --no-recursion 6 exec /usr/local/bin/bash /vol/gnu/src/gcc/gcc-dist/libjava/configure '--cache-file=./config.cache' '--host=alpha-dec-osf5.1b' '--build=alpha-dec-osf5.1b' '--enable-multilib' '--prefix=/vol/gcc' '--with-local-prefix=/vol/gcc' '--disable-nls' '--disable-libmudflap' '--with-gcc-version-trigger=/vol/gnu/src/gcc/gcc-dist/gcc/version.c' '--enable-languages=c,c++,java,objc' '--program-transform-name=s,y,y,' '--srcdir=/vol/gnu/src/gcc/gcc-dist/libjava' '--with-target-subdir=alpha-dec-osf5.1b' 'CPPFLAGS=-O2 -g -O2 -mieee' 'build_alias=alpha-dec-osf5.1b' 'host_alias=alpha-dec-osf5.1b' 'target_alias=alpha-dec-osf5.1b' --enable-ltdl-convenience --with-auxdir=/vol/gnu/src/gcc/gcc-dist $ac_configure_extra_args --no-create --no-recursion ac_configure_args=--enable-multilib '--cache-file=./config.cache' '--host=alpha-dec-osf5.1b' '--build=alpha-dec-osf5.1b' '--enable-multilib' '--prefix=/vol/gcc' '--with-local-prefix=/vol/gcc' '--disable-nls' '--disable-libmudflap' '--with-gcc-version-trigger=/vol/gnu/src/gcc/gcc-dist/gcc/version.c' '--enable-languages=c,c++,java,objc' '--program-transform-name=s,y,y,' '--srcdir=/vol/gnu/src/gcc/gcc-dist/libjava' '--with-target-subdir=alpha-dec-osf5.1b' 'CPPFLAGS=-O2 -g -O2 -mieee' 'build_alias=alpha-dec-osf5.1b' 'host_alias=alpha-dec-osf5.1b' 'target_alias=alpha-dec-osf5.1b' --enable-ltdl-convenience --with-auxdir=/vol/gnu/src/gcc/gcc-dist s,@CFLAGS@,-O2 -g -O2 -mieee,;t t s,@CXXFLAGS@,-g -O2 -mieee,;t t s,@LIBGCJ_CFLAGS@, -mieee,;t t s,@LIBGCJ_CXXFLAGS@, -mieee,;t t s,@LIBGCJ_JAVAFLAGS@, -mieee,;t t s,@CPPFLAGS@,-O2 -g -O2 -mieee,;t t s,@IEEESPEC@,-mieee,;t t I.e. the extra space is present here, too. In libltdl/config.log, I find $ /vol/gnu/src/gcc/gcc-dist/libjava/libltdl/configure --prefix=/vol/gcc --cache-file=./config.cache --host=alpha-dec-osf5.1b --build=alpha-dec-osf5.1b --enable-multilib --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --disable-libmudflap --with-gcc-version-trigger=/vol/gnu/src/gcc/gcc-dist/gcc/version.c--enable-languages=c,c++,java,objc --program-transform-name=s,y,y, --srcdir=/vol/gnu/src/gcc/gcc-dist/libjava --with-target-subdir=alpha-dec-osf5.1b CPPFLAGS=-O2 -g -O2 -mieee build_alias=alpha-dec-osf5.1b host_alias=alpha-dec-osf5.1b target_alias=alpha-dec-osf5.1b --enable-ltdl-convenience --with-auxdir=/vol/gnu/src/gcc/gcc-dist --cache-file=.././config.cache --srcdir=/vol/gnu/src/gcc/gcc-dist/libjava/libltdl Here, the extra space is gone. Rainer
[Bug ada/18417] [4.0 Regression]Ada bootstrap failure on IRIX 6.5: tb-gcc.c missing
--- Additional Comments From ro at techfak dot uni-bielefeld dot de 2004-11-24 14:34 --- Subject: Re: [4.0 Regression]Ada bootstrap failure on IRIX 6.5: tb-gcc.c missing hainque at act-europe dot fr writes: pinskia at gcc dot gnu dot org wrote: Caused by: 2004-06-25 Olivier Hainque [EMAIL PROTECTED] * tracebak.c: Introduce support for a GCC infrastructure based implementation of __gnat_backtrace. I'm out of the office until monday and will only be able to properly address that by then. You may just not define USE_GCC_UNWINDER in the SGI section to workaround in the meantime. The tb-gcc.c file is still missing from the repository. Would you please add it soon? Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18417
[Bug ada/18417] [4.0 Regression]Ada bootstrap failure on IRIX 6.5: tb-gcc.c missing
--- Additional Comments From charlet at adacore dot com 2004-11-24 14:37 --- Subject: Re: [4.0 Regression]Ada bootstrap failure on IRIX 6.5: tb-gcc.c missing The tb-gcc.c file is still missing from the repository. Would you please add it soon? Thanks for the reminder, I indeed forgot about it. I'll work on it as soon as possible. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18417
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Additional Comments From hjl at lucon dot org 2004-11-24 14:38 --- I don't mind a big testcase as long as it is all I need on a regular Linux installation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug target/18630] can't find a register in class `GENERAL_REGS' when trying to make Firefox 1.0
--- Additional Comments From Dirk dot Schwartzkopff at gmx dot de 2004-11-24 14:44 --- -O2 works fine for me. Now I get an other problem: /mnt/mozilla/netwerk/resources make /usr/bin/gmake export gmake[1]: Wechsel in das Verzeichnis »/mnt/mozilla/netwerk/resources« gmake[1]: Für das Target »export« gibt es nichts zu tun. gmake[1]: Verlassen des Verzeichnisses »/mnt/mozilla/netwerk/resources« /usr/bin/gmake libs gmake[1]: Wechsel in das Verzeichnis »/mnt/mozilla/netwerk/resources« +++ making chrome /mnt/mozilla/netwerk/resources = ../../dist/bin/chrome/comm.jar +++ updating chrome ../../dist/bin/chrome/installed-chrome.txt +++ content,install,url,jar:resource:/chrome/comm.jar!/content/necko/ +++ overriding content/necko/contents.rdf updating: content/necko/contents.rdf (stored 0%) +++ making chrome /mnt/mozilla/netwerk/resources = ../../dist/bin/chrome/en-US.jar error: file '../../toolkit/locales/en-US/chrome/necko/contents.rdf' doesn't exist at ../../config/make-jars.pl line 418. gmake[1]: *** [libs] Fehler 2 gmake[1]: Verlassen des Verzeichnisses »/mnt/mozilla/netwerk/resources« make: *** [all] Fehler 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
[Bug middle-end/18641] [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-11-24
14:50 ---
We have here the following situation before reload:
(insn 27 46 28 7 (set (reg:DI 118 [ D.1118 ])
(const_int 4294967295 [0x])) 313 {*movdi_internal32} (nil)
(nil))
where reg 118 gets assigned a stack slot, and due to the large
stack frame size this slot is not directly addressable.
Now, when reverting my patch, what happens is that LEGITIMIZE_RELOAD_ADDRESS
finds a way to construct the stack slot address, and the constant is reloaded
into a register (pair):
(insn 67 46 66 7 (set (reg:DI 2 r2)
(const_int 4294967295 [0x])) 313 {*movdi_internal32} (nil)
(nil))
(insn 66 67 27 7 (set (reg:SI 9 r9)
(plus:SI (reg/f:SI 30 r30)
(const_int 131072 [0x2]))) 64 {*addsi3_internal1} (nil)
(nil))
(insn 27 66 28 7 (set (mem:DI (plus:SI (reg:SI 9 r9)
(const_int 40 [0x28])) [0 D.1118+0 S8 A8])
(reg:DI 2 r2)) 313 {*movdi_internal32} (nil)
(nil))
Note that insn 27 now uses the r - o alternative of *movdi_internal32;
this is allowed only if the address is offsettable.
Now, that address is the one that was constructed by
LEGITIMIZE_RELOAD_ADDRESS. Unfortunately, reload common code has
no way to actually look at what LEGITIMIZE_RELOAD_ADDRESS does,
so that it could decide whether or not the address constructed
is in fact an offsettable one or not.
Before my 2004-08-22 patch, reload simply always assumed the address
is offsettable, due to an apparent bug in LEGITIMIZE_RELOAD_ADDRESS
handling: reload assumed that L_R_A would always completely replace
the address by a single base register (which of course implies the
address is offsettable). This bug caused problems on s390.
My patch removed this erroneous assumption that L_R_A always completly
replaces the address; as we don't know anything further we then have
to make the conservative assumption that addresses constructed by L_R_A
are never offsettable. Thus reload doesn't accept the r - o alternative
of *movdi_internal32 any more; the one it chooses instead is f - m.
This implies reloading the constant into a floating point register,
and that's what reload goes ahead and does:
(insn 67 46 66 7 (set (reg:DI 32 f0)
(const_int 4294967295 [0x])) 313 {*movdi_internal32} (nil)
(nil))
(insn 66 67 27 7 (set (reg:SI 2 r2)
(plus:SI (reg/f:SI 30 r30)
(const_int 131072 [0x2]))) 64 {*addsi3_internal1} (nil)
(nil))
(insn 27 66 28 7 (set (mem:DI (plus:SI (reg:SI 2 r2)
(const_int 40 [0x28])) [0 D.1118+0 S8 A8])
(reg:DI 32 f0)) 313 {*movdi_internal32} (nil)
(nil))
However, the insn 67 emitted thus is not actually implemented by
any of the alternatives or splitters; thus the crash later on.
This would appear to be a latent bug in the rs6000 back end.
Reload insns generated during the gen_reload phase *must* be
implemented by the backend. I'm not familiar enough with the
platform to suggested the best way to do so; one obvious option
would be force the constant to memory using either from within
the movdi expander or via a secondary input reload.
The next question is whether the new code, if implemented
correctly, is better or worse than the old code -- again this
is a rs6000 back-end issue.
However, one middle-end question remains: while it is obviously
wrong for reload to assume that L_R_A always results in a simple
base register, at least on rs6000 is appears to be the case that
L_R_A always results in an *offsettable* address. If this is true,
we might be missing optimizations by not exploiting that knowledge
in reload any more.
One way might be to extend the L_R_A interface in a way that would
allow the back end to inform the middle end about properties of
the address is has constructed; I'm not sure how this interface
should look in detail.
The other option would be to simply go back to having the middle end
assume the L_R_A constructed addresses are always offsettable. This
could be implemented by something like the following patch:
Index: reload.c
===
RCS file: /cvs/gcc/gcc/gcc/reload.c,v
retrieving revision 1.258
diff -c -p -r1.258 reload.c
*** reload.c9 Nov 2004 17:29:02 - 1.258
--- reload.c24 Nov 2004 14:49:04 -
*** find_reloads (rtx insn, int replace, int
*** 3189,3196
((ind_levels ? offsettable_memref_p (operand)
: offsettable_nonstrict_memref_p (operand))
/* A reloaded address is offsettable because it is now
! just a simple register indirect. */
!|| address_reloaded[i] == 1))
|| (REG_P (operand)
REGNO (operand) = FIRST_PSEUDO_REGISTER
reg_renumber[REGNO (operand)] 0
--- 3189,3198
[Bug rtl-optimization/18648] New: empty loop / missed-optimization
# cat empty-loop.c
long f()
{
long i, ret = 0;
for (i = 0; i 10; i++)
ret++;
return ret;
}
# gcc empty-loop.c -O2 -S cat empty-loop.s
f:
pushl %ebp
movl$9, %eax
movl%esp, %ebp
.p2align 4,,15
.L5:
decl%eax
jns .L5
popl%ebp
movl$10, %eax
ret
source # http://gcc.gnu.org/ml/gcc-help/2004-11/msg00169.html
--
Summary: empty loop / missed-optimization
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at pld-linux dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: pentium3-pld-linux
GCC host triplet: pentium3-pld-linux
GCC target triplet: pentium3-pld-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18648
[Bug target/18630] can't find a register in class `GENERAL_REGS' when trying to make Firefox 1.0
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-11-24 14:56 --- This new problem doesn't appear to have anything to do with GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
[Bug tree-optimization/18648] gcc does not remove empty loops
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 14:58 --- There might already be a bug about removing empty loops somewhere. -- What|Removed |Added Severity|minor |enhancement Component|rtl-optimization|tree-optimization Keywords||missed-optimization Summary|empty loop / missed-|gcc does not remove empty |optimization|loops http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18648
[Bug regression/18643] [3.4 Regression] fixincludes breaks RTEMS
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-11-24 15:02 --- (In reply to comment #1) Nothing in fixincludes look wrong. The new fixincludes do not apply to limits.h at all. But the old one probably did. The limits.h gcc-3.4 2004-11-17 produced, contains fragments of limitx.h, which I presume to be having been added by fixincludes and friends. Does this work on the mainline, I don't know, it's been a while since mainline built successfully for me. Yesterday's mainline did not build at all. I assume so as HP could build MMIX just recently, earlier today. Are you sure that this is not a newlib bug but then again HP built MMIX with the combined tree. I would not want to exclude this possibility. Throughout the years, there repeatedly had been issues with RTEMS/newlib's limits.h. Also, note: RTEMS limits.h-machinery is not identical with generic newlib's limits.h machinery. RTEMS has custom limits.h and syslimits.h in newlib's sources. Furthermore, diffing the gcc-sources didn't reveal anything obivous. However, I noticed the following when diffing my build-logs: @@ -10319,7 +10327,7 @@ chmod a+r include/syslimits.h) Fixing headers into /users/rtems/src/rpms/BUILD/rtems-4.7-avr-rtems4.7-gcc-newlib-gcc3.4.4newlib1.12.0/build/gcc/include for avr-unknown-rtems4.7 target echo timestamp stmp-fixinc -if true ; then \ +if [ -f /opt/rtems-4.7/lib/gcc/avr-rtems4.7/3.4.4/../../../../avr-rtems4.7/sys-include/limits.h ] ; then \ cat ../../gcc-3.4.4/gcc/limitx.h ../../gcc-3.4.4/gcc/glimits.h ../../gcc-3.4.4/gcc/limity.h tmp-xlimits.h; \ else \ cat ../../gcc-3.4.4/gcc/glimits.h tmp-xlimits.h; \ So the actual question is: What has set LIMITS_H_TEST to true before, and why isn't it set true anymore? I am seeing further substancial differences in the build-log, but the diff above seems to be the origin of this breakdown. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18643
[Bug target/18630] can't find a register in class `GENERAL_REGS' when trying to make Firefox 1.0
--- Additional Comments From giovannibajo at libero dot it 2004-11-24 15:15 --- Was that an internal compiler error or a general error? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
[Bug target/16800] PowerPC - Unnecessary rldicl
--- Additional Comments From dje at watson dot ibm dot com 2004-11-24 15:21 --- Subject: Re: PowerPC - Unnecessary rldicl The test for mode == Pmode is present because most of the fast scc patterns depend on carry. PowerPC carry depends on the mode of the processor. If the mode of the comparison is not the mode of the processor (Pmode), the scc patterns cannot be applied and the modified cost should not be applied. Similarly, only EQ, GTU, and LTU costs are handled because those are the fast scc patterns active for PowerPC. I did not include the costs for the original POWER architecture. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16800
[Bug target/18630] can't find a register in class `GENERAL_REGS' when trying to make Firefox 1.0
--- Additional Comments From Dirk dot Schwartzkopff at gmx dot de 2004-11-24 15:37 --- I think it was an error in the configuration and/or source of firefox. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
[Bug target/18630] can't find a register in class `GENERAL_REGS' when trying to make Firefox 1.0
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-11-24 15:40 --- It was an error message correctly explaining that (and why) a specific inline assembly statment could not be compiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
[Bug c++/18649] New: terminate called after throwing - IOT/Abort trap (core dumped)
The threaded program used in this ticket crashes intermittently. The error is
sometimes terminate called after throwing and something unwind called
recursively. A sample stack trace is shown below.
#0 0x in ?? ()
#1 0xd254ece4 in __gxx_exception_cleanup (code=539406920, exc=0x2026b228)
at /home/downloads/gcc/gcc-3.4.2/libstdc++-v3/libsupc++/eh_throw.cc:52
#2 0xd26bdab0 in _Unwind_DeleteException (exc=0x2026b228)
at /home/downloads/gcc/gcc-3.4.2/gcc/unwind.inc:277
#3 0xd2548530 in __cxa_end_catch ()
at /home/downloads/gcc/gcc-3.4.2/libstdc++-v3/libsupc++/eh_catch.cc:119
#4 0x149c in thread_handler ()
#5 0xd004a410 in _pthread_body () from /usr/lib/libpthreads.a(shr_xpg5.o)
#6 0x in ?? ()
#7 0x in ?? ()
Previous frame identical to this frame (corrupt stack?)
To reproduce the bug, copy this program to main.cpp and compile it with g++ -
pthread main.cpp. Then, run the program with while ./a.out do sleep 1;
done. After a minute or so, the program will die. (It doesn't die every
time, so that is why you need to run it in the loop.)
==
#include pthread.h
#include stdio.h
#include unistd.h
#include sys/timeb.h
#define NUM_THREADS 200
#define NUM_LOOPS 1000
pthread_mutexattr_t cs_attr;
pthread_mutex_t cs;
int cnt;
void*
thread_handler(void* idptr)
{
printf(thread_handler (start)\n);
for (int i=0; iNUM_LOOPS; ++i)
{
try
{
throw nothing;
}
catch(...)
{
//pthread_mutex_lock(cs);
time_t now = time(0);
struct tm now_tm;
localtime_r(now, now_tm);
//pthread_mutex_unlock(cs);
}
}
pthread_mutex_lock(cs);
++cnt;
pthread_mutex_unlock(cs);
printf(thread_handler (stop)\n);
return NULL;
}
int
main(int argc, char** argv)
{
pthread_mutexattr_settype(cs_attr, PTHREAD_MUTEX_RECURSIVE);
pthread_mutex_init(cs, cs_attr);
cnt = 0;
for (int i=0; iNUM_THREADS; ++i)
{
pthread_attr_t attr;
int err = pthread_attr_init(attr);
if (err != 0)
{
printf(Could not initialize thread [errno=%d]\n, err);
return 1;
}
err = pthread_attr_setdetachstate(attr, PTHREAD_CREATE_DETACHED);
if (err != 0)
{
printf(Could not set detachable thread [errno=%d]\n, err);
return 1;
}
pthread_t thread;
err = pthread_create(thread, attr, thread_handler, (void*)NULL);
if (err != 0)
{
printf(Could not create thread [errno=%d]\n, err);
return 1;
}
}
bool stop = false;
while(!stop)
{
sleep(1);
pthread_mutex_lock(cs);
stop = (cnt == NUM_THREADS);
printf(*** cnt = %d\n, cnt);
pthread_mutex_unlock(cs);
}
return 0;
}
==
gcc was configured as follows.
configure --enable-threads=posix --prefix=/usr/local/gcc/gcc-3.x.x --enable-lang
uages=c,c++ --disable-multilib
--
Summary: terminate called after throwing - IOT/Abort trap (core
dumped)
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: askees at appfluent dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: powerpc-ibm-aix5.1.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18649
[Bug regression/18643] [3.4 Regression] fixincludes breaks RTEMS
--- Additional Comments From joel at oarcorp dot com 2004-11-24 15:50 --- Subject: Re: [3.4 Regression] fixincludes breaks RTEMS corsepiu at gcc dot gnu dot org wrote: --- Additional Comments From corsepiu at gcc dot gnu dot org 2004-11-24 15:02 --- (In reply to comment #1) Nothing in fixincludes look wrong. The new fixincludes do not apply to limits.h at all. But the old one probably did. The limits.h gcc-3.4 2004-11-17 produced, contains fragments of limitx.h, which I presume to be having been added by fixincludes and friends. Does this work on the mainline, I don't know, it's been a while since mainline built successfully for me. Yesterday's mainline did not build at all. I assume so as HP could build MMIX just recently, earlier today. Are you sure that this is not a newlib bug but then again HP built MMIX with the combined tree. I would not want to exclude this possibility. Throughout the years, there repeatedly had been issues with RTEMS/newlib's limits.h. Also, note: RTEMS limits.h-machinery is not identical with generic newlib's limits.h machinery. RTEMS has custom limits.h and syslimits.h in newlib's sources. Furthermore, diffing the gcc-sources didn't reveal anything obivous. However, I noticed the following when diffing my build-logs: @@ -10319,7 +10327,7 @@ chmod a+r include/syslimits.h) Fixing headers into /users/rtems/src/rpms/BUILD/rtems-4.7-avr-rtems4.7-gcc-newlib-gcc3.4.4newlib1.12.0/build/gcc/include for avr-unknown-rtems4.7 target echo timestamp stmp-fixinc -if true ; then \ +if [ -f /opt/rtems-4.7/lib/gcc/avr-rtems4.7/3.4.4/../../../../avr-rtems4.7/sys-include/limits.h ] ; then \ cat ../../gcc-3.4.4/gcc/limitx.h ../../gcc-3.4.4/gcc/glimits.h ../../gcc-3.4.4/gcc/limity.h tmp-xlimits.h; \ else \ cat ../../gcc-3.4.4/gcc/glimits.h tmp-xlimits.h; \ So the actual question is: What has set LIMITS_H_TEST to true before, and why isn't it set true anymore? gcc/config/t-rtems in gcc 3.3.5 and the version on the 3.4 branch are the same example the 3.3.5 version has this: # RTEMS uses newlib which does not require prototype fixing STMP_FIXPROTO = There was a patch about 15 months ago moving that logic to config.gcc. Is fixproto being set to yes somehow in config.gcc for avr-rtems? Do you have a special stanza in your config.gcc for that target that is not checked in? The checked in source only has avr-*-* and ends up setting fixproto=yes. That would explain this. Does this happen on other targets? --joel I am seeing further substancial differences in the build-log, but the diff above seems to be the origin of this breakdown. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18643
[Bug tree-optimization/18650] New: Failure in tree-ssa/loop-2.c with powerpc64 with biarch
I didn't find a bug report for this yet.
This regressoin roughly started happening Oct 26-27. as it shows up in
testresults from Janis Johson here. (32-bit default32 compiler. Regression
only at -m64)
http://gcc.gnu.org/ml/gcc-testresults/2004-10/msg01382.html
Interestingly, this also shows up in my 64-bit default64 compiler but at -m32:
http://gcc.gnu.org/ml/gcc-testresults/2004-10/msg01391.html
The check that is failing in the test case is:
/* { dg-final { scan-tree-dump-times \\* 17 0 vars } } */
/* { dg-final { scan-tree-dump-times \\+ 17 1 vars } } */
as 17 * iter is not getting reduced.
I played with the testcase a bit using a 32-bit biarch compiler w/ -m64 and
noticed a couple things.
1) Changing the iter var from 'int' to a 'long' seems to let the test pass again
. The test case is tiny so I'll original code here:
struct bla
{
char x[187];
int y;
char z[253];
} arr_base[100];
void xxx(void)
{
int iter;
for (iter = 0; iter 100; iter++)
arr_base[iter].y = 17 * iter;
}
2) Dumps of t52.ivopts pass (from dump-tree-all-all), look funny:
(add_to_evolution
(loop_nb = 1)
(chrec_before = 100)
(to_add = 1)
(res = {100, +, 4294967295}_1))
(evolution_function = {100, +, 4294967295}_1))
(set_scalar_evolution
(scalar = ivtmp.1_5)
(scalar_evolution = {100, +, 4294967295}_1))
)
,as 4294967295 looks quite peculiar.and would have expected 0 there.
I'll attach the entire loop-2.c.t52.ivopts for 32 bit and for 64 bit, in case
someone wise in the ways of tree/loops/scalarev has interest.
--
Summary: Failure in tree-ssa/loop-2.c with powerpc64 with biarch
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jgrimm2 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18650
[Bug other/18623] 4 * libiberty local variables set but never used
--- Additional Comments From schlie at comcast dot net 2004-11-24 16:10 --- but could be helpful, and couldn't hurt to clean things up rather than maintain an otherwise needless difference, as the fix has already also been imported into gdb's sources as well; as just a though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18623
[Bug tree-optimization/18650] Failure in tree-ssa/loop-2.c with powerpc64 with biarch
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-24 16:14 --- Created an attachment (id=7596) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7596action=view) ivopts dump at -m32 (when testcase passes) ivopts dump at -m32 (when testcase passes) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18650
[Bug tree-optimization/18650] Failure in tree-ssa/loop-2.c with powerpc64 with biarch
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-24 16:15 --- Created an attachment (id=7597) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7597action=view) ivopts dump at -m64 (when testcase fails) ivopts dump at -m64 (when testcase fails) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18650
[Bug c++/18639] poor out-of-memory handling
--- Additional Comments From bangerth at dealii dot org 2004-11-24 16:49 --- This has been discussed numerous times, and the main problem people had in coming up with better diagnostics is that the operating system does not communicate to a program why it is being killed. What happens is that the OS allows you to allocate lots of memory, but it doesn't actually provide it until you actually start writing to these pages for the first time. At that time, you write to an invalid page, a signal is raised, and the OS tries to come up with some physical memory to put behind that address. If it is out of memory, it can't do that and returns to the application without physical memory. The program then aborts with an invalid memory access, just as if you tried to dereference a null pointer. The program itself has no idea what happened, and the signal handler for the invalid memory access is invoked which then prints out the error message you have seen. What would probably have to happen for this to be fixed is to change the OS so that it gives an indication what is going wrong when it can't satisfy memory requests. That's a much bigger problem, though, than to just change a compiler message. After all, we don't want to lose the error message one gets when the compiler really tries to dereference a null pointer. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18639
[Bug target/18631] [4.0 Regression] missing error messages passing vectors with -mno-altivec -mabi=altivec
--- Additional Comments From janis187 at us dot ibm dot com 2004-11-24 16:53 --- Oops, in the submission I said There used to be error messages for passing vectors by value or returning vectors from functions if AltiVec support was on but the non-AltiVec ABI was used. That should be: There used to be error messages ... if AltiVec support was not on and the AltiVec ABI was used. The AltiVec ABI says that vectors that map to hardware vectors are passed in vector registers. That variant of the ABI is the default but can be turned off with -mabi=no-altivec, which is useful for binary compatibility with modules that will be used on multiple types of PowerPC-64 hardware. The ABI doesn't cover generic vectors that don't map to hardware vectors, but GCC passes them by reference for either variant of the ABI. It probably doesn't specifically cover the case of generic vectors that map to hardware vectors when AltiVec support isn't enabled, but that seems surprising enough that it ought to continue to be an error. I personally think it ought to be an error to pass any synthetic vector by value unless it is specifically covered by the ABI, but that's another mess that no one wants to touch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18631
[Bug middle-end/18071] [3.4/4.0 Regression] -Winline does not respect -fno-default-inline
--- Additional Comments From joseph at codesourcery dot com 2004-11-24 16:57 --- Subject: Re: [3.4/4.0 Regression] -Winline does not respect -fno-default-inline On Wed, 24 Nov 2004, giovannibajo at libero dot it wrote: JSM, do you agree with Steven's analysys? It looks like DECL_DECLARED_INLINE should just mean there, so the C frontend might be wrong in this regard. I agree the C front end should set DECL_DECLARED_INLINE when a function is declared inline. Before looking for a problem in that regard, make sure that (a) DECL_DECLARED_INLINE is what is checked for the diagnostics in question, (b) it is indeed not set for the relevant decl. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug c++/18651] New: Error compiling nurbs
-- Summary: Error compiling nurbs Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: e7677215 at est dot fib dot upc dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18651
[Bug c++/18652] New: [4.0 regression] ICE on invalid redeclaration
Mainline crashes on the following invalid code snippet: = int A; templateint struct A; = bug.cc:6: error: 'templateint anonymous struct A' redeclared as different kind of symbol bug.cc:5: error: previous declaration of 'int A' bug.cc:6: internal compiler error: tree check: expected class 'declaration', have 'exceptional' (error_mark) in push_template_decl_real, at cp/pt.c:3152 Please submit a full bug report, [etc.] The release branches are not affected. According to Phils's regression hunter the regression was introduced in February: : Search converges between 2004-02-01-trunk (#445) and 2004-03-01-trunk (#446). -- Summary: [4.0 regression] ICE on invalid redeclaration Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: minor Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18652
[Bug c++/18470] [4.0 regression] array bound rejected as non-constant in template
--- Additional Comments From mark at codesourcery dot com 2004-11-24 17:38 --- Subject: Re: [4.0 regression] array bound rejected as non-constant in template giovannibajo at libero dot it wrote: --- Additional Comments From giovannibajo at libero dot it 2004-11-24 10:05 --- Yes, Mark, but it used to work just a few weeks ago, and it is a rejects-valid. I understand. That's why I left the target for this PR set at 4.0. We have an ever-growing list of these, with respect to using-declarations. None of these have ever worked correctly; they've all worked because we made various mistakes in name lookup. Every time we fix name lookup, we introduce more problems with using-declarations, because our using-declarations are not really using-declarations, but just access specifiers. For example, we broke things in this area when we introduced two-phase name lookup. The correct fix -- and, I suspect, the only correct fix -- is to implement using-declarations for classes correctly. I'd love to do that, but depending on how big of a job it is, it may not happen for 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18470
[Bug bootstrap/18645] Impossible to built gcc 3.4.3 with gcc 3.2.2; missing crti.o; no *.i* files available
--- Additional Comments From Dirk dot Schwartzkopff at gmx dot de 2004-11-24 17:40 --- configure --disable-multilib works fine -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18645
[Bug libfortran/18653] New: open call should open for read-only if open for read/write fails.
If we have the following program: OPEN(10,FILE='wup.in',STATUS='OLD') CLOSE(10, STATUS='KEEP') END And a data file that is readable by everyone and writable by nobody: $ ll wup.in -r--r--r-- 1 sjeother 0 Nov 24 08:43 wup.in gfortran will fail on the open (because it tries to open for read write), other compilers will open for read-only if they cannot open for reading and writing. Opening for read-only is not required by the Fortran standard but it is how most Fortran compilers (HP, Intel, g77) behave. -- Summary: open call should open for read-only if open for read/write fails. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: ia64-hp-hpux11.23 GCC host triplet: ia64-hp-hpux11.23 GCC target triplet: ia64-hp-hpux11.23 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18653
[Bug c++/18530] [4.0 regression] Bogus warnings about shadowed variables __ct, __dt
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-24 17:55 --- Fixed in GCC 4.0. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18530
[Bug c++/18530] [4.0 regression] Bogus warnings about shadowed variables __ct, __dt
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-24 17:57 --- Subject: Bug 18530 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-24 17:57:02 Modified files: gcc/cp : ChangeLog cp-tree.h decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/warn: Wshadow-3.C Log message: PR c++/18530 * cp-tree.h (CTOR_NAME): Remove. (DTOR_NAME): Remove. * decl.c (initialize_predefined_identifiers): Add spaces to the end of constructor and destructor names. PR c++/18530 * g++.dg/warn/Wshadow-3.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4490r2=1.4491 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gccr1=1.1071r2=1.1072 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1330r2=1.1331 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4640r2=1.4641 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wshadow-3.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18530
[Bug libfortran/18653] open call should open for read-only if open for read/write fails.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 18:03 --- Confirmed, I will reopen the other bug and close it as a dup of this one. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-24 18:03:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18653
[Bug c++/18652] [4.0 regression] ICE on invalid redeclaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 18:05 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-24 18:05:11 date|| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18652
[Bug c++/18651] Error compiling nurbs
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 18:06 --- Can you attach the preprocessed source, see http://gcc.gnu.org/bugs.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18651
[Bug c++/18586] [4.0 regression] ICE on invalid template member declaration
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-24 18:10 --- Fixed in GCC 4.0. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18586
[Bug c++/18586] [4.0 regression] ICE on invalid template member declaration
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-24 18:11 --- Subject: Bug 18586 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-24 18:10:27 Modified files: gcc/cp : ChangeLog parser.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: deduce3.C Log message: PR c++/18586 * parser.c (cp_parser_init_declarator): Do not pop scope twice. PR c++/18586 * g++.dg/template/crash27.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4491r2=1.4492 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gccr1=1.279r2=1.280 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4641r2=1.4642 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/deduce3.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18586
[Bug tree-optimization/18650] Failure in tree-ssa/loop-2.c with powerpc64 with biarch
-- What|Removed |Added Keywords||missed-optimization Summary|Failure in tree-ssa/loop-2.c|Failure in tree-ssa/loop-2.c |with powerpc64 with biarch |with powerpc64 with biarch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18650
[Bug preprocessor/18176] Bootstrap fail at FreeBSD 5.3-RC1 (and FreeBSD 5.1) with --enable-bootstrap configure option
--- Additional Comments From wanderer at rsu dot ru 2004-11-24 18:16 --- Can't test patch. Bootstrap current GCC mainline terminated early (with and wightout patch): ---8X--- /usr/local/bin/msgfmt --statistics -o po/tr.gmo /home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/po/tr.po 142 translated messages, 16 fuzzy translations, 9 untranslated messages. gmake[2]: Leaving directory `/usr/home/wanderer/pkg/build/gcc/obj/stage1- libcpp' gmake[1]: *** No rule to make target `maybe-all-stage1-fixincludes', needed by `all-stage1-gcc'. Stop. gmake[1]: Leaving directory `/usr/home/wanderer/pkg/build/gcc/obj' gmake: *** [stage1-bubble] Error 2 ---8X--- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18176
[Bug libfortran/18297] gfortran : file opening fails if only read access
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 18:18 --- Just closing as a dup of bug 18653 (there was some talk about this on the mailing list). *** This bug has been marked as a duplicate of 18653 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18297
[Bug libfortran/18653] open call should open for read-only if open for read/write fails.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 18:18 --- *** Bug 18297 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||mimo2 at free dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18653
[Bug middle-end/18641] [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr
--- Additional Comments From dje at gcc dot gnu dot org 2004-11-24 18:18 --- Allowing the middle-end to know that the L_R_A address is offsettable looks like a better solution to me. The design is an issue for RTH. One possibility is a target macro to decide if L_R_A addresses should be assumed offsettable: #if LRA_OFFSETTABLE || address_reloaded[i] 0 #else || address_reloaded[i] == 1 #endif ) Finer granlarity information from LRA is more complicated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18641
[Bug tree-optimization/18648] gcc does not remove empty loops
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 18:26 --- Confirmed, there was some hope for this on 4.1.0, it is too late for 4.0.0. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-24 18:26:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18648
[Bug c++/18192] Serious Performance Bug depending on a donothing destructor declaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 18:27 --- This might have to do with execeptions. -- What|Removed |Added Severity|critical|normal Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18192
[Bug libstdc++/18654] New: Shrink-to-fit std::string::reserve() calls can reallocate copy string contents unnecessarily
I've noticed that calling std::string::reserve() in a shrink- to-fit request can sometimes end up allocating exactly the same amount of memory as the string already had. This is because _S_create() rounds up allocations of over 128 bytes to 128 byte subpages, and of over 4k to 4k pages, for more efficient use of malloc(). When the reallocated block is the same size as the original one, the entire contents of the string are effectively being copied unnecessarily. Further shrink-to-fit calls keep doing it, too, since the requested capacity remains less than the actual capacity. NOTES: 1. I first noticed this in February 2004, and submitted a possible patch for it at the time - the original mailing list thread started here: http://gcc.gnu.org/ml/libstdc++/2004-02/msg00179.html Unfortunately, problems at my end caused the patch to get hung up on FSF assignment issues, so it couldn't go in. I've now resolved these issues, and Benjamin Kosnik has asked me to put the original report here in Bugzilla for further discussion. 2. Recent CVS (as of November 2004) no longer uses the 128 byte subpages, courtesy of Paolo Carlini's work to improve std::string. -- Summary: Shrink-to-fit std::string::reserve() calls can reallocate copy string contents unnecessarily Product: gcc Version: 3.4.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nferguso at eso dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18654
[Bug c++/18649] terminate called after throwing - IOT/Abort trap (core dumped)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 18:41 --- This is already fixed in 3.4.3 and it is a dup of bug 13391. *** This bug has been marked as a duplicate of 13391 *** -- What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18649
[Bug target/13391] AIX: collect2 emits bad code with duplicated symbols
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 18:42 --- *** Bug 18649 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||askees at appfluent dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13391
[Bug libstdc++/18654] Shrink-to-fit std::string::reserve() calls can reallocate copy string contents unnecessarily
--- Additional Comments From nferguso at eso dot org 2004-11-24 18:43 --- Created an attachment (id=7598) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7598action=view) Old patch for basic_string.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18654
[Bug libstdc++/18654] Shrink-to-fit std::string::reserve() calls can reallocate copy string contents unnecessarily
--- Additional Comments From nferguso at eso dot org 2004-11-24 18:44 --- Created an attachment (id=7599) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7599action=view) Old patch for basic_string.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18654
[Bug middle-end/17909] [4.0 Regression] ICE: verifiy_stms failed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 18:49 --- New patch here: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02048.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17909
[Bug libstdc++/18654] Shrink-to-fit std::string::reserve() calls can reallocate copy string contents unnecessarily
--- Additional Comments From nferguso at eso dot org 2004-11-24 18:53 --- I've attached the most recent version of my original patch as basic_string.h.diff and basic_string.tcc.diff. WARNING: these patches are against CVS as of 12 February 2004, so they are well out of date - they came from this message on the mailing list: http://gcc.gnu.org/ml/libstdc++/2004-02/msg00212.html Recent discussion seems to be moving towards the position that this approach is no longer the best. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18654
[Bug libgcj/18222] [4.0 Regression] libjava bootstrap failure on Tru64 UNIX: CPPFLAGS changed in libltdl
--- Additional Comments From kcook at gcc dot gnu dot org 2004-11-24 18:59 --- I'm up to three bugs here of which two are very related. The first bug is that somewhere during bootstrap an extra space is getting tacked on CFLAGS. I'll try to track down where that happens. I'm pretty sure that some mistake is happening in the toplevel Makefile.* wizardy. Obviously this is not right, but on the other hand it really shouldn't matter much. Usually, this extra space doesn't matter due to another bug shown by Gerald's testcase which shows that at some invocation of a submake an intentional trailing space is gets stripped from CFLAGS. I do think I know why this bogus space causes bootstrap failures on Alpha and that is the config/mt-alphaieee which appends -mieee to CFLAGS, this means our wayward trailing space in CFLAGS is now longer a trailing space and so it doesn't get stripped when it is calls a submake at some point. So what does all this have to do with CPPFLAGS? Well, this bug reports exposes that we do have a more troubling problem in that CPPFLAGS is getting assigned -O2 -g -O2. CPPFLAGS is for the preproccesor and only should have things like -I ../dir or -DMACRO. This came from this patch here by Sean McNeil: http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01736.html I think DJ rightfully questioned this patch at the time. It's clearly not correct to abuse CPPFLAGS that way IMO. I propose that patch be reverted. If one wants to pass something to libgfortran, use FCFLAGS (which actually may need to get added to the toplevel to pass down to libgfortran). For C++ use CXXFLAGS. That's what those two flags are for. Great, but why should that matter you ask? Because autoconf considers CPPFLAGS to be a precious (unchanging) variable, but not CFLAGS. So, reverting Sean's patch should fix both problems even with the first two bugs. Finally, I'm pretty sure that this bug is misfiled, since is a bug within our build machinery. But we don't have category for that. -- What|Removed |Added CC||sean at mcneil dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18222
[Bug c++/18635] use of uninitialised reference accepted in C++ front end
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 19:07 --- No this is valid code (but undefined): int a = a; a is injected before the equals so the code is about the same as: int *a = *a; -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635
[Bug c++/18306] seems not possible to specialize a template member function
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 19:11 --- Invalid, as what you are doing is called explicit specializtion and when this happens you instantiate the template and now you are violating the one defintional rule (which is 14.7/5 in the C++ standard). Note that if you use 3.4.0, it works with adding template. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18306
[Bug ada/17321] Illegal program not detected, name hidden by use clauses
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 19:16 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.0.0 Last reconfirmed|-00-00 00:00:00 |2004-11-24 19:16:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17321
[Bug ada/17320] Illegal program not detected, RM 3.9.3(11)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 19:17 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.0.0 Last reconfirmed|-00-00 00:00:00 |2004-11-24 19:17:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17320
[Bug libgcj/17978] Binary Compatibility: use _Jv_AllocBytes to allocate interface dispatch tables
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 19:18 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-24 19:18:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17978
[Bug ada/17985] GNAT accepts extension aggregate where expexted type is not extension
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 19:19 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||accepts-invalid Known to fail||4.0.0 Last reconfirmed|-00-00 00:00:00 |2004-11-24 19:19:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17985
[Bug ada/14997] ncurses build fails with Ada
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 19:32 --- On the mainline I get a different ICE: +===GNAT BUG DETECTED==+ | 4.0.0 20041121 (experimental) (powerpc-apple-darwin7.6.0) GCC error: | | RTL flag check: MEM_VOLATILE_P used with unexpected rtx code | |'const_int' in extract_fixed_bit_field, at expmed.c:1687 | | Error detected at pq.adb:79:5| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +== + -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14997
[Bug ada/15102] Building shared libgnat may fail linking non-PIC object files
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 19:33 --- Does this work now or at least gets passed this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15102
[Bug ada/16099] Wrong output from legal program
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-24 19:35 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-24 19:35:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16099
[Bug preprocessor/18176] Bootstrap fail at FreeBSD 5.3-RC1 (and FreeBSD 5.1) with --enable-bootstrap configure option
--- Additional Comments From wanderer at rsu dot ru 2004-11-24 19:38 --- Additinal note: patch break current GCC mainline bootstrap _without_ --enable- bootstrap option: ---8X stage1/xgcc -Bstage1/ -B/home/wanderer/pkg/gcc/i386-unknown-freebsd5.3/bin/ - c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict- prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros - Wold-style-definition -Werror -fno-common -DHAVE_CONFIG_H-I. -I. - I/home/wanderer/pkg/build/gcc/src/gcc/gcc/gcc - I/home/wanderer/pkg/build/gcc/src/gcc/gcc/gcc/. - I/home/wanderer/pkg/build/gcc/src/gcc/gcc/gcc/../include -I./../intl - I/home/wanderer/pkg/build/gcc/src/gcc/gcc/gcc/../libcpp/include - I/usr/local/include gtype-desc.c -o gtype-desc.o cc1: warnings being treated as errors gtype-desc.c: In function 'gt_ggc_mx_answer': gtype-desc.c:743: warning: passing argument 1 of 'gt_ggc_mx_cpp_token' discards qualifiers from pointer target type gtype-desc.c: In function 'gt_ggc_mx_cpp_macro': gtype-desc.c:790: warning: passing argument 1 of 'gt_ggc_mx_cpp_token' discards qualifiers from pointer target type gtype-desc.c: In function 'gt_ggc_mx_cpp_token': gtype-desc.c:827: warning: passing argument 1 of 'gt_ggc_mx_cpp_token' discards qualifiers from pointer target type gtype-desc.c: In function 'gt_pch_nx_answer': gtype-desc.c:2210: warning: passing argument 1 of 'gt_pch_nx_cpp_token' discards qualifiers from pointer target type gtype-desc.c: In function 'gt_pch_nx_cpp_macro': gtype-desc.c:2258: warning: passing argument 1 of 'gt_pch_nx_cpp_token' discards qualifiers from pointer target type gtype-desc.c: In function 'gt_pch_nx_cpp_token': gtype-desc.c:2297: warning: passing argument 1 of 'gt_pch_nx_cpp_token' discards qualifiers from pointer target type gmake[2]: *** [gtype-desc.o] Error 1 gmake[2]: Leaving directory `/usr/home/wanderer/pkg/build/gcc/obj/gcc' gmake[1]: *** [stage2_build] Error 2 gmake[1]: Leaving directory `/usr/home/wanderer/pkg/build/gcc/obj/gcc' gmake: *** [bootstrap] Error 2 ---X8 Without patch GCC mainline bottstrap doesn't have this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18176
[Bug debug/18655] New: Incorrect data in .debug_frame section for PowerPC
The output generated in the .debug_frame section is incorrect, as follows:
1. The return_address_register in the CIE is given as 65. In the ABI
supplement for the PowerPC, this is the ID of the Floating Point Status and
Control Register. This should probably have been 108, the ID of the Link
Register.
2. In the body of the FDE, the return address is put into in register 108.
Since the CIE specifies that the return is in register 65, this value is lost
when traversing the stack
These two register IDs should be the same. (They were both 65 in the 3.2
version of the compiler). The simple test case provided generates one CIE, and
three FDE entries. The FDEs for main and sub2 are both inconsistent with the
CIE.
Results from gcc -v:
Reading specs from /usr/lib/gcc/ppc64-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-
checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-
exceptions --enable-languages=c,c++,objc,java,f77 --enable-java-awt=gtk --
host=ppc64-redhat-linux --build=ppc64-redhat-linux --target=ppc64-redhat-linux -
-with-cpu=default32
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
command line:
g++ -v x.cpp
Original source file (x.cpp):
//#include stdio.h
int sub1(int x)
{
return x + 1;
}
int sub2(int x)
{
for (int i = 0; i 10; i++)
x = sub1(x + i);
return 0;
}
int main(int argc, char** argv)
{
return sub2(argc);
}
//--
Preprocessed file x.ii:
# 1 x.cpp
# 1 /home/pett/dev/test//
# 1 built-in
# 1 command line
# 1 x.cpp
int sub1(int x)
{
return x + 1;
}
int sub2(int x)
{
for (int i = 0; i 10; i++)
x = sub1(x + i);
return 0;
}
int main(int argc, char** argv)
{
return sub2(argc);
}
--
Summary: Incorrect data in .debug_frame section for PowerPC
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pett at ca dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18655
[Bug target/18655] Incorrect data in .debug_frame section for PowerPC
-- What|Removed |Added Component|debug |target Keywords||wrong-debug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18655
[Bug c++/18556] [4.0 Regression] C++ debug is broken
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18556
