Graphite merge regressed PR 35107 ?
PR 35107 appears to have regressed on mainline. It was originally fixed on the trunk and 4.3 back in February: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35107 http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00187.html The summary is that gmp and mpfr and unnecessarily linked into all executables (e.g. xgcc, gcov) whereas they should only be used for programs that are linked with libbackend.a like cc1. It matters when gmp/mpfr are shared libs. There's no reason to slow down the startup of all programs we provide by dynamically loading these libraries. During the graphite merge, $GMPLIBS was added back to the generic $LIBS variable and gets linked into everything. Is this really necessary? http://gcc.gnu.org/viewcvs/trunk/gcc/Makefile.in?r1=139854r2=139893 If it's not necessary, IMHO this should be fixed again before we branch 4.4. I think CLOOGLIBS and PPLLIBS need to be moved to the right places, but I don't have those libraries to test it myself. Since it would touch all the places my original patch did, perhaps it would be best to create a BACKENDLIBS and/or BACKENDDEPS variable and hook GMPLIBS, CLOOGLIBS and PPLLIBS in there. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
Rats, I'm getting another bootstap failure on sparc-sun-solaris2.10.
This time it happens in stage2 building libgcc. What happens is that
when it runs configure for stage2 libgcc, I get:
checking for suffix of object files...
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
whereupon in config.log I see:
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
The stage2 gcc cannot compile this simple program. The stage1
compiler can, so looks like stage2 was miscompiled. Running it under
gdb doesn't yield any useful info.
This is fairly recent as I got a successful testresult here:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00402.html
The top of the gcc/ChangeLog from the working checkout was:
2007-09-07 Sterling Augustine [EMAIL PROTECTED]
* config/xtensa/lib2funcs.S (__xtensa_sync_caches): Use an ISYNC even
if there is no i-cache.
Is anyone else having a similar problem?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
On Sun, 9 Sep 2007, David Edelsohn wrote: Kaveh The stage2 gcc cannot compile this simple program. The stage1 Kaveh compiler can, so looks like stage2 was miscompiled. Running it under Kaveh gdb doesn't yield any useful info. I am seeing the same failure on AIX. The SEGV on AIX is in postreload.c and if I recompile that file without optimization, the config test succeeds. David Ditto. Program received signal SIGSEGV, Segmentation fault. 0x002cf780 in reload_combine_note_store (dst=0xff0b90e0, set=value optimized out, data=0x0) at ../../egcc-SVN20070909/gcc/postreload.c:1018 1018 reg_state[i].store_ruid = reload_combine_ruid; (gdb) Any luck figuring out which patch broke it? --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
i386.md:3705: error: undefined machine-specific constraint at this point: Y
I just got this error building a cross-compiler from sparc-sun-solaris2.10 targetted to i686-unknown-linux-gnu. This worked as recently as last week: build/genoutput ../../egcc-SVN20070216/gcc/config/i386/i386.md insn-conditions.md tmp-output.c config/i386/i386.md:3705: error: undefined machine-specific constraint at this point: Y config/i386/i386.md:3705: note: in operand 1 make[2]: *** [s-output] Error 1 anybody else seeing this? Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Extra gcc-3.3 java failures when using expect-5.43
From: Andrew Haley aph at redhat dot com Kaveh R. Ghazi writes: After I upgraded to expect-5.43, I noticed that I'm getting extra java failures on the 3.3 branch on x86_64-unknown-linux-gnu. Other gcc branches do not have problems. http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01295.html I'm using an expect-5.43 binary on x86_64 that was compiled on i686 if that matters. When I back down to expect-5.42.1, the testsuite results go back to normal. Anyone else seeing this? Could you post a snippet of the log, please? Andrew. There was nothing useful in libjava.log to indicate what the problem is. I reran the testsuite with --verbose and all the errors show up like this: spawning command /tmp/kg/33/build/x86_64-unknown-linux-gnu/./libjava/gij ArrayStore exp6 file5 close result is child killed: SIGABRT FAIL: ArrayStore execution - gij test Don't know who/what is sending a SIGABRT. Again, if I back down to expect 5.42.1 everything passes. And also it only occurs on the 3.3 branch. Other branches and mainline pass fine. So there may be a diff in the testsuite harness. (?) --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Extra gcc-3.3 java failures when using expect-5.43
After I upgraded to expect-5.43, I noticed that I'm getting extra java failures on the 3.3 branch on x86_64-unknown-linux-gnu. Other gcc branches do not have problems. http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01295.html I'm using an expect-5.43 binary on x86_64 that was compiled on i686 if that matters. When I back down to expect-5.42.1, the testsuite results go back to normal. Anyone else seeing this? Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Extra 3.3 -fpic/-fPIC testsuite failures on i686-unknown-linux-gnu
I've been running testsuites on i686-pc-linux-gnu with -fpic/-fPIC passes and have been getting some extra failures. Some of them involve inline asm, which I'm not familiar with. I'd like to solicit some feedback on which ones are: A. Fixable in the testcase. B. Expected failures, use dg-skip-if or equiv. C. Real bugs in the compiler, file a PR. Here's the batch from the 3.3.x branch as noted in this posting: http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00029.html Thanks, --Kaveh gcc.c-torture/compile/2804-1.c: In function `f': gcc.c-torture/compile/2804-1.c:8: error: can't find a register in class `GENERAL_REGS' while reloading `asm' collect2: ld returned 1 exit status FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O1 FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O2 FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -g FAIL: gcc.c-torture/execute/20020720-1.c compilation, -Os (The above has generally been skipped when it fails) gcc.dg/2009-1.c: In function `main': gcc.dg/2009-1.c:69: warning: asm operand 0 probably doesn't match constraints gcc.dg/2009-1.c:69: error: impossible constraint in `asm' FAIL: gcc.dg/asm-names.c (test for excess errors) Excess errors: /tmp/ccQzl6UN.o(.text+0x13): undefined reference to `__GLOBAL_OFFSET_TABLE_' /tmp/ccQzl6UN.o(.text+0x3e): undefined reference to `__GLOBAL_OFFSET_TABLE_' /tmp/ccQzl6UN.o(.text+0x5b): undefined reference to `__GLOBAL_OFFSET_TABLE_' g++.old-deja/g++.pt/asm1.C:7: error: can't find a register in class `BREG' while reloading `asm' g++.old-deja/g++.pt/asm2.C:13: error: can't find a register in class `BREG' while reloading `asm' -- Kaveh R. Ghazi [EMAIL PROTECTED]
Extra 3.4 -fpic/-fPIC testsuite failures on i686-unknown-linux-gnu
Here are the excess -fpic/-fPIC testsuite failures from 3.4.x on i686-pc-linux-gnu as noted here: http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00028.html I'd like some assistance categorizing them please. A. Fixable in the testcase. B. Expected failures, use dg-skip-if or equiv. C. Real bugs in the compiler, file a PR. I've noted those that are regressions from 3.3.x. Thanks, --Kaveh gcc.c-torture/compile/2804-1.c:12: error: can't find a register in class `GENERAL_REGS' while reloading `asm' FAIL: gcc.c-torture/compile/2804-1.c -O0 (test for excess errors) gcc.c-torture/compile/2804-1.c:12: error: can't find a register in class `GENERAL_REGS' while reloading `asm' FAIL: gcc.c-torture/compile/2804-1.c -O1 (test for excess errors) (The -O1 failure is a regression from 3.3.x, -O0 isn't.) gcc.dg/2009-1.c: In function `main': gcc.dg/2009-1.c:69: warning: asm operand 0 probably doesn't match constraints gcc.dg/2009-1.c:69: error: impossible constraint in `asm' FAIL: gcc.dg/2009-1.c (test for excess errors) (Same in 3.3.x) gcc.dg/20020919-1.c:132: error: PIC register `%ebx' clobbered in `asm' gcc.dg/20020919-1.c:177: error: PIC register `%ebx' clobbered in `asm' gcc.dg/20020919-1.c:186: error: PIC register `%ebx' clobbered in `asm' gcc.dg/20020919-1.c:231: error: PIC register `%ebx' clobbered in `asm' gcc.dg/20020919-1.c:244: error: PIC register `%ebx' clobbered in `asm' (Regression from 3.3.x.) gcc.dg/clobbers.c: In function `main': gcc.dg/clobbers.c:13: error: PIC register `ebx' clobbered in `asm' FAIL: gcc.dg/clobbers.c (test for excess errors) (Regression from 3.3.x.) FAIL: gcc.dg/i386-387-3.c scan-assembler fldpi (New testcase.) FAIL: gcc.dg/i386-387-4.c scan-assembler fldpi (New testcase.) FAIL: gcc.dg/i386-cmov1.c scan-assembler sar[^\\n]*magic_namea FAIL: gcc.dg/i386-cmov1.c scan-assembler sar[^\\n]*magic_nameb FAIL: gcc.dg/i386-cmov1.c scan-assembler sar[^\\n]*magic_namec FAIL: gcc.dg/i386-cmov1.c scan-assembler shr[^\\n]*magic_named FAIL: gcc.dg/i386-cmov1.c scan-assembler shr[^\\n]*magic_namee FAIL: gcc.dg/i386-cmov1.c scan-assembler shr[^\\n]*magic_namef (New testcase.) FAIL: gcc.dg/i386-local2.c scan-assembler-not sub[^\\n]*sp (New testcase.) FAIL: gcc.dg/i386-mul.c scan-assembler and[^\\n]*magic (New testcase.) FAIL: gcc.dg/i386-ssetype-1.c scan-assembler andpd[^\\n]*magic FAIL: gcc.dg/i386-ssetype-1.c scan-assembler andnpd[^\\n]*magic FAIL: gcc.dg/i386-ssetype-1.c scan-assembler xorpd[^\\n]*magic FAIL: gcc.dg/i386-ssetype-1.c scan-assembler orpd[^\\n]*magic FAIL: gcc.dg/i386-ssetype-1.c scan-assembler movapd[^\\n]*magic (Regression from 3.3.x, but the testcase has changed.) FAIL: gcc.dg/i386-ssetype-3.c scan-assembler andps[^\\n]*magic FAIL: gcc.dg/i386-ssetype-3.c scan-assembler andnps[^\\n]*magic FAIL: gcc.dg/i386-ssetype-3.c scan-assembler xorps[^\\n]*magic FAIL: gcc.dg/i386-ssetype-3.c scan-assembler orps[^\\n]*magic FAIL: gcc.dg/i386-ssetype-3.c scan-assembler movaps[^\\n]*magic (Ditto.) FAIL: gcc.dg/i386-ssetype-5.c scan-assembler pand[^\\n]*magic FAIL: gcc.dg/i386-ssetype-5.c scan-assembler pandn[^\\n]*magic FAIL: gcc.dg/i386-ssetype-5.c scan-assembler pxor[^\\n]*magic FAIL: gcc.dg/i386-ssetype-5.c scan-assembler por[^\\n]*magic (Ditto.) FAIL: gcc.dg/sibcall-6.c execution test (New testcase.) FAIL: g++.dg/eh/omit-frame-pointer2.C execution test (New testcase.) g++.old-deja/g++.pt/asm1.C:6: error: can't find a register in class `BREG' while reloading `asm' (Same as 3.3.x) g++.old-deja/g++.pt/asm2.C:16: error: can't find a register in class `BREG' while reloading `asm' (Same as 3.3.x) FAIL: ext/enc_filebuf/char/13189.cc (test for excess errors) ext/enc_filebuf/char/13189.cc:30: error: expected init-declarator before '' token ext/enc_filebuf/char/13189.cc:30: error: expected `,' or `;' before '' token ext/enc_filebuf/char/13189.cc:38: error: `filebuf_type' undeclared (first use this function) ext/enc_filebuf/char/13189.cc:38: error: (Each undeclared identifier is reported only once for each function it appears in.) ext/enc_filebuf/char/13189.cc:38: error: expected `;' before fbuf ext/enc_filebuf/char/13189.cc:40: error: `fbuf' undeclared (first use this function) (New testcase.) FAIL: ext/enc_filebuf/wchar_t/13189.cc (test for excess errors) ext/enc_filebuf/wchar_t/13189.cc:30: error: expected init-declarator before '' token ext/enc_filebuf/wchar_t/13189.cc:30: error: expected `,' or `;' before '' token ext/enc_filebuf/wchar_t/13189.cc:38: error: `filebuf_type' undeclared (first use this function) ext/enc_filebuf/wchar_t/13189.cc:38: error: (Each undeclared identifier is reported only once for each function it appears in.) ext/enc_filebuf/wchar_t/13189.cc:38: error: expected `;' before fbuf ext/enc_filebuf/wchar_t/13189.cc:40: error: `fbuf' undeclared (first use this function) (New testcase.) -- Kaveh R. Ghazi [EMAIL PROTECTED]
Extra 4.0 -fpic/-fPIC testsuite failures on i686-unknown-linux-gnu
Finally, here are the excess -fpic/-fPIC testsuite failures from mainline on i686-pc-linux-gnu as noted here: http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00027.html I'd like some assistance categorizing them please. A. Fixable in the testcase. B. Expected failures, use dg-skip-if or equiv. C. Real bugs in the compiler, file a PR. Mainline also has all of the excess -fpic/-fPIC failures from 3.4.x, I didn't bother to repeat them. The ones below are all from new testcases. Because of that, I don't know if they are regressions. (If it turns out they are PR-worthy I'll check later.) Thanks, --Kaveh FAIL: gcc.c-torture/execute/builtins/strlen-3.c execution, -O2 FAIL: gcc.c-torture/execute/builtins/strlen-3.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/builtins/strlen-3.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/builtins/strlen-3.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/builtins/strlen-3.c execution, -O3 -g (New testcase.) FAIL: gcc.dg/assign-warn-3.c (test for warnings, line 9) FAIL: gcc.dg/assign-warn-3.c (test for warnings, line 13) (New testcase.) gcc.dg/i386-asm-3.c: In function 'main':^M gcc.dg/i386-asm-3.c:18: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'^M FAIL: gcc.dg/i386-asm-3.c (test for excess errors) (New testcase.) FAIL: gcc.dg/tree-ssa/ssa-dce-2.c scan-tree-dump-times if 0 (New testcase.) 27_io/basic_istream/extractors_character/wchar_t/1.cc:52: void test01(): Assertion `i1 == i2' failed. (New testcase.) -- Kaveh R. Ghazi [EMAIL PROTECTED]
PCH merge: bootstrap failure, gengtype consumes all file descriptors
I've been getting bootstrap failures in stage1 on solaris2.7 when running gengtype, it says: opening output file: Too many open files On my box, the default fd limit is 64. You can probably reproduce this error by artificially setting your soft limit low enough. You also might need to start from a totally clean build dir, since when I rerun gengtype, it sometimes succeeds. Note it seems like we're just barely at the limit since when I increase the limit to 65, it always works. I tracked how many open file descriptors we keep open in main after each function call in gengtype. fds openafter call -- 3 (prior to open_base_files) 12 open_base_files 29 write_gc_types Then inside write_gc_roots there are loops over the `variables' parameter which call get_output_file_with_visibility. The FILE*s returned by this function call are never closed so the fd count goes up until it hits the system limit. (And BTW the return value is not checked so we don't know we got an error.) Later on in close_output_files, where we do check the error status, we notice all the fds are used up and give the error message above. As I mentioned above, when I set the limit to 65, it works. And later on the open fd count drops back to 3 (std in,out,err) so apparently this is not an fd leak, everything is tracked and closed. Instead we have a design problem in that the code expects to have all these descriptors available to it. I think that's a bad assumption. --Kaveh -- Kaveh R. Ghazi Director of Systems Architecture [EMAIL PROTECTED] Qwest Solutions
