glib-2.16.1 fails to compile in scannerapi.c and produces "internal compiler error". I've dramatically reduced the test case, here it is: - scannerapi.c - scannerapi.i - stderr - command used: gcc -v -save-temps -o scannerapi.o -c scannerapi.c >& stderr ----- scannerapi.c (start) ------------ #define myassert(n1, cmp, n2) do { signed long __n1 = (n1), \ __n2 = (n2); if (__n1 cmp __n2) ; else myassert_message \ (__FILE__, __PRETTY_FUNCTION__, #n1 " " #cmp " " #n2, __n1, \ #cmp, __n2); } while (0) void myassert_message ( char const *file, char const *func, char const *expr, long double g1, char const *cmp, long double g2 ) __attribute__((__noreturn__)); typedef struct { struct _GScanner *scanner; } SF; void test_scanner_tokens (void) { SF *fix; char buf[] = "1234567"; int const buflen = undeclared0(buf); char mytokbuf[] = "abcde"; int i; undeclared2 (fix->scanner, buf, buflen); myassert (undeclared3 (fix->scanner), ==, 1); undeclared5 (fix->scanner); myassert (undeclared1 (fix->scanner), ==, 0); myassert (undeclared4 (fix->scanner), ==, mytokbuf[0]); for (i = 1; i < 1; i++) { myassert (undeclared5 (fix->scanner), ==, mytokbuf[i]); }; myassert (undeclared5 (fix->scanner), ==, 0); return; } ----- scannerapi.c (end) ------------ ----- scannerapi.i (start) ------------ # 1 "scannerapi.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "scannerapi.c" void myassert_message ( char const *file, char const *func, char const *expr, long double g1, char const *cmp, long double g2 ) __attribute__((__noreturn__)); typedef struct { struct _GScanner *scanner; } SF; void test_scanner_tokens (void) { SF *fix; char buf[] = "1234567"; int const buflen = undeclared0(buf); char mytokbuf[] = "abcde"; int i; undeclared2 (fix->scanner, buf, buflen); do { signed long __n1 = (undeclared3 (fix->scanner)), __n2 = (1); if (__n1 == __n2) ; else myassert_message ("scannerapi.c", __PRETTY_FUNCTION__, "undeclared3 (fix->scanner)" " " "==" " " "1", __n1, "==", __n2); } while (0); undeclared5 (fix->scanner); do { signed long __n1 = (undeclared1 (fix->scanner)), __n2 = (0); if (__n1 == __n2) ; else myassert_message ("scannerapi.c", __PRETTY_FUNCTION__, "undeclared1 (fix->scanner)" " " "==" " " "0", __n1, "==", __n2); } while (0); do { signed long __n1 = (undeclared4 (fix->scanner)), __n2 = (mytokbuf[0]); if (__n1 == __n2) ; else myassert_message ("scannerapi.c", __PRETTY_FUNCTION__, "undeclared4 (fix->scanner)" " " "==" " " "mytokbuf[0]", __n1, "==", __n2); } while (0); for (i = 1; i < 1; i++) { do { signed long __n1 = (undeclared5 (fix->scanner)), __n2 = (mytokbuf[i]); if (__n1 == __n2) ; else myassert_message ("scannerapi.c", __PRETTY_FUNCTION__, "undeclared5 (fix->scanner)" " " "==" " " "mytokbuf[i]", __n1, "==", __n2); } while (0); }; do { signed long __n1 = (undeclared5 (fix->scanner)), __n2 = (0); if (__n1 == __n2) ; else myassert_message ("scannerapi.c", __PRETTY_FUNCTION__, "undeclared5 (fix->scanner)" " " "==" " " "0", __n1, "==", __n2); } while (0); return; } ----- scannerapi.i (end) ------------ ----- stderr (start) ------------ Using built-in specs. Target: sparc64-sun-solaris2.8 Configured with: /tmp/local/tmp/gcc/gcc-4.4.0/configure --prefix=/tmp/local/unixutil/gcc-4.4.0 --with-local-prefix=/usr/local/myplace --enable-languages=c,c++,fortran --with-gmp=/tmp/local/unixutil/gmpTMP --with-mpfr=/tmp/local/unixutil/mpfrTMP --with-cpu=v9 --build=sparc64-sun-solaris2.8 --disable-multilib Thread model: posix gcc version 4.4.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'scannerapi.o' '-c' '-mcpu=v9' /tmp/local/unixutil/gcc-4.4.0/bin/../libexec/gcc/sparc64-sun-solaris2.8/4.4.0/cc1 -E -quiet -v -iprefix /tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/sparc64-sun-solaris2.8/4.4.0/ -D__arch64__ -D__sparcv9 scannerapi.c -mcpu=v9 -fpch-preprocess -o scannerapi.i ignoring nonexistent directory "/tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/sparc64-sun-solaris2.8/4.4.0/../../../../sparc64-sun-solaris2.8/include" ignoring nonexistent directory "/usr/local/myplace/include" ignoring duplicate directory "/tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/../../lib/gcc/sparc64-sun-solaris2.8/4.4.0/include" ignoring duplicate directory "/tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/../../lib/gcc/sparc64-sun-solaris2.8/4.4.0/include-fixed" ignoring nonexistent directory "/tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/../../lib/gcc/sparc64-sun-solaris2.8/4.4.0/../../../../sparc64-sun-solaris2.8/include" #include "..." search starts here: #include <...> search starts here: /tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/sparc64-sun-solaris2.8/4.4.0/include /tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/sparc64-sun-solaris2.8/4.4.0/include-fixed /tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/../../include /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'scannerapi.o' '-c' '-mcpu=v9' /tmp/local/unixutil/gcc-4.4.0/bin/../libexec/gcc/sparc64-sun-solaris2.8/4.4.0/cc1 -fpreprocessed scannerapi.i -quiet -dumpbase scannerapi.c -mcpu=v9 -auxbase-strip scannerapi.o -version -o scannerapi.s GNU C (GCC) version 4.4.0 (sparc64-sun-solaris2.8) compiled by GNU C version 4.4.0, GMP version 4.3, MPFR version 2.4.1. warning: GMP header version 4.3 differs from library version 4.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 9ca553a0ebde423c17b189104de35a45 scannerapi.c: In function 'test_scanner_tokens': scannerapi.c:36: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. ----- stderr (end) ------------
This one appears to have fallen through the cracks. Reported exactly one year ago, and now accidentally shows up in my search because my brain believed we still live in 2009... Oh well. I tried to reproduce this with a GCC 4.4.2 cross-compiler from x86_64-linux to sparc64-sun-solaris2.8: Reading specs from ./specs Target: sparc64-sun-solaris2.8 Configured with: ../gcc-4.4.2/configure --enable-languages=c --with-mpc=/opt/ --disable-bootstrap --disable-libmudflap --disable-libssp --target=sparc64-sun-solaris2.8 Thread model: posix gcc version 4.4.2 (GCC) COLLECT_GCC_OPTIONS='-B.' '-S' '-mcpu=v9' '-fpreprocessed' '-v' ./cc1 -fpreprocessed scannerapi.i -quiet -dumpbase scannerapi.i -mcpu=v9 -auxbase scannerapi -version -fpreprocessed -o scannerapi.s GNU C (GCC) version 4.4.2 (sparc64-sun-solaris2.8) compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version 2.4.1-p2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 8f402920727a69779efab15585e5a4c9 COMPILER_PATH=./ LIBRARY_PATH=./ COLLECT_GCC_OPTIONS='-B.' '-S' '-mcpu=v9' '-fpreprocessed' '-v' Rainer, could you see if you can confirm this one (with 4.4/4.5/trunk)? Could the "warning: GMP header version 4.3 differs from library version 4.3.0." have something to do with the segfault?
I tried this morning to reproduce this bug with GCC 4.4.3 and GCC 4.5.0 and i didn't succeed (that is: the GCC 4.4.0 bug is gone).
Subject: Re: preprocessor fails with myassertion > ------- Comment #1 from steven at gcc dot gnu dot org 2010-04-23 22:43 ------- > This one appears to have fallen through the cracks. Reported exactly one year > ago, and now accidentally shows up in my search because my brain believed we > still live in 2009... Oh well. I'll try to go through the Solaris bugs in the near future, but have concentrated on getting the 4.5 release in shape until now. > Rainer, could you see if you can confirm this one (with 4.4/4.5/trunk)? I don't have a 4.4 tree around at the moment, but the testcase works fine on both 4.5 and mainline *with a sparc-sun-solaris2.10* compiler. The problem might be related to the sparc64-sun-solaris2.8 configuration, but I refuse to test that because I simply don't have the manpower to double testing effort when a 32-bit default bi-arch compiler handles this just fine. I'd rather remove the sparcv9-sun-solaris2.* configuration than deal with this. > Could the "warning: GMP header version 4.3 differs from library version 4.3.0." > have something to do with the segfault? I doubt that, actually, though I haven't checked GMP versioning in detail. Maybe Eric has a sparcv9 compiler around and can easily check this? Rainer
> I'll try to go through the Solaris bugs in the near future, but have > concentrated on getting the 4.5 release in shape until now. I totally missed it as well... > Maybe Eric has a sparcv9 compiler around and can easily check this? I only have 4.3.5, 4.5.1 and 4.6.0 compilers for sparc64-sun-solaris2.x at the moment, I'll test if someone can attach the preprocessed source. The submitter said that the problem has disappeared so the PR can be closed though.
Subject: Re: preprocessor fails with myassertion >> Maybe Eric has a sparcv9 compiler around and can easily check this? > > I only have 4.3.5, 4.5.1 and 4.6.0 compilers for sparc64-sun-solaris2.x at the > moment, I'll test if someone can attach the preprocessed source. The submitter > said that the problem has disappeared so the PR can be closed though. Preprocessed source is embedded in the original submission.
> Preprocessed source is embedded in the original submission. Yes, that's precisely why I asked to attach it instead.
Created attachment 20509 [details] preprocessed test case, copied from comment #0
Thanks, Steven. So, one year later, ...
The never ending story of qsort on Solaris 8: Program received signal SIGSEGV, Segmentation fault. 0x0000000100bb7204 in allocno_priority_compare_func (v1p=0x102f3d268, v2p=0x102f3d278) at /nile.build/botcazou/gcc-4.4/src/gcc/ira-color.c:1738 1738 pri1 = allocno_priorities[ALLOCNO_NUM (a1)]; (gdb) bt #0 0x0000000100bb7204 in allocno_priority_compare_func (v1p=0x102f3d268, v2p=0x102f3d278) at /nile.build/botcazou/gcc-4.4/src/gcc/ira-color.c:1738 #1 0xffffffff7f253a9c in qsort () from /usr/lib/64/libc.so.1 #2 0x0000000100bbeb10 in fast_allocation () at /nile.build/botcazou/gcc-4.4/src/gcc/ira-color.c:3274 #3 0x0000000100bbf0b0 in ira_color () at /nile.build/botcazou/gcc-4.4/src/gcc/ira-color.c:3339 #4 0x0000000100b3a7ac in ira (f=0x0) at /nile.build/botcazou/gcc-4.4/src/gcc/ira.c:3152 #5 0x0000000100b3b104 in rest_of_handle_ira () at /nile.build/botcazou/gcc-4.4/src/gcc/ira.c:3309 IRA has been seriously shaken after 4.4.0 so the issue (absence of total order on the sorted array) may have been de facto fixed. Let's just pretend that.