Matthias Klose wrote:
Frank Heckenbach writes:
Matthias Klose wrote:
[CC to gpc@gnu.de; the gpc version is the RC2, the gcc version 2.95.4 CVS]
Philip Blundell writes:
The version of gpc in the 2001-12-23 upload doesn't seem to work on arm, sparc, m68k or s390; they all seem to segfault somewhere during the build.
../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O3 -DRTS_RELEASE_STRING="'`cat /build/buildd/gcc-2.95-2.95.4.ds7/src-native/gcc/p/ rts/rts-version`'" --unit-path=/build/buildd/gcc-2.95-2.95.4.ds7/src-native/gc c/p/rts --automake `cat needed-options` /build/buildd/gcc-2.95-2.95.4.ds7/src-n ative/gcc/p/rts/heap.pas xgpc: Internal compiler error: program gpc1 got fatal signal 11 make[5]: *** [heap.o] Error 1
on sparc it fails in another file:
../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O3 -DRTS_RELEASE_STRING="'`cat /home/doko/2.95/gcc-2.95-2.95.4.ds7/src-native/gcc/p/rts/rts-version`'" --unit-path=/home/doko/2.95/gcc-2.95-2.95.4.ds7/src-native/gcc/p/rts --automake `cat needed-options` /home/doko/2.95/gcc-2.95-2.95.4.ds7/src-native/gcc/p/rts/endian.pas xgpc: Internal compiler error: program gpc1 got fatal signal 11 make[5]: *** [endian.o] Error 1
Stupid bug. Fix attached.
No, doesn't work:
(gdb) set args endian.i -quiet -dumpbase endian.pas -g -O3 -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -version -funit-path=/home/doko/2.95/gcc-2.95-2.95.4.ds8/src-native/gcc/p/rts -o endian.s (gdb) run Starting program: /home/doko/2.95/gcc-2.95-2.95.4.ds8/build-native/gcc/p/rts/../.././gpc1 endian.i -quiet -dumpbase endian.pas -g -O3 -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -version -funit-path=/home/doko/2.95/gcc-2.95-2.95.4.ds8/src-native/gcc/p/rts -o endian.s GNU Pascal version 2.95.4 20020102 (Debian prerelease) (sparc-linux) compiled by GNU C version 2.95.4 20020102 (Debian prerelease). GNU Pascal version is actually 20011222, based on gcc-2.95.4 20020102 (Debian prerelease)
Program received signal SIGSEGV, Segmentation fault. print_int_cst_octal (c=0x2f000388) at /home/doko/2.95/gcc-2.95-2.95.4.ds8/src-native/gcc/p/../dbxout.c:1597 1597 int width = TYPE_PRECISION (TREE_TYPE (c)); (gdb) bt #0 print_int_cst_octal (c=0x2f000388) at /home/doko/2.95/gcc-2.95-2.95.4.ds8/src-native/gcc/p/../dbxout.c:1597 Cannot access memory at address 0xd0028038 (gdb) list 1592 tree c; 1593 { 1594 unsigned HOST_WIDE_INT high = TREE_INT_CST_HIGH (c); 1595 unsigned HOST_WIDE_INT low = TREE_INT_CST_LOW (c); 1596 int excess = (3 - (HOST_BITS_PER_WIDE_INT % 3)); 1597 int width = TYPE_PRECISION (TREE_TYPE (c)); 1598 1599 /* GDB wants constants with no extra leading "1" bits, so 1600 we need to remove any sign-extension that might be 1601 present. */
That's another bug now (at least another one than the one you sent me the last gdb log about (in private mail) which the patch I sent was for -- actually I'm slightly confused; I'm not sure if we're talking about one or several problems at all).
I can't reproduce this problem -- perhaps you can me a more detailed gdb output (including, e.g., `i s').
Anyway, I see you're using `-g'. Maybe that's the problem. It's a known issue (and listed in our known bugs list) that the debug info generation is quite unstable (AFAICS, that's mostly a backend problem, so I'm not sure if I can easily fix it, even if we find the cause of the crash ...). So, perhaps you'll just have to use no `-g' (e.g., `RTSFLAGS=-g0', and `EXTRA_PFLAGS=-g0' when running the test suite).
Frank