This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
IA32 breakage. Was: Fix for build failure on Intel is now available
Gerald Pfeifer wrote:
> On Thu, 2 Mar 2000, Tim Josling wrote:
> > See http://gcc.gnu.org/ml/gcc-patches/2000-03/msg00001.html
> > [...]
> > I haven't tested this yet but my patch was similar and did fix
> > the problem, so it is probably OK.
>
> Jan installed that patch one hour ago and I verified that my Intel
> platforms (FreeBSD 3.4 and Linux) are back in bootstrap-land.
I'm glad your intel platforms bootstrap. Not one of mine will
regardless of the bootstrap compiler used.
i686-pc-udk:
stage1/xgcc -Bstage1/ -B/usr/local/egcs-udk/i686-pc-udk/bin/ -DIN_GCC -W -Wall -Wtraditional -O2 -g -DHAVE_CONFIG_H -o genattrtab \
genattrtab.o rtl.o bitmap.o ggc-none.o print-rtl.o errors.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac `
./genattrtab /play/egcs/gcc/config/i386/i386.md > tmp-attrtab.c
genattrtab: Unknown value `' for `type' attribute
make[1]: *** [s-attrtab] Error 33
make: *** [bootstrap] Error 2
i586-sco-sysv5uw7.1.1 hangs at
stage2/xgcc -Bstage2/ -B/usr/local/i586-sco-sysv5uw7.1.1/bin/ -c -DIN_GCC -W -Wall -Wtraditional -O2 -g -I. -I.. -I/home/robertl/src/egcs/gcc/ch -I/home/robertl/src/egcs/gcc/ch/.. -I/home/robertl/src/egcs/gcc/ch/../config -I/home/robertl/src/egcs/gcc/ch/../../include /home/robertl/src/egcs/gcc/ch/lex.c
It consumed 48minutes of 550 Xeon time before I killed cc1.
i686-pc-sco3.2v5.0.5 ICEs at
./xgcc -B/usr/local/i686-pc-sco3.2v5.0.5/bin/ -B./ -I/usr/local/i686-pc-sco3.2v5.0.5/include -DIN_GCC -g -I./include -I. -I/play/egcs/gcc -I/play/egcs/gcc/config -I/play/egcs/gcc/../include -mcoff -fno-omit-frame-pointer \
-DCRT_BEGIN -DCRTSTUFFS_O -finhibit-size-directive \
-fno-inline-functions -fno-exceptions -g0 \
-c /play/egcs/gcc/crtstuff.c -o crtbeginS.o
/play/egcs/gcc/crtstuff.c: In function `__do_global_dtors_aux':
/play/egcs/gcc/crtstuff.c:184: Internal compiler error in `?', at toplev.c:1475
Please submit a full bug report.
As recently as a few days ago, it would compile this one and then abort
when building __gcc_bcmp in libgcc2.a
The bounds violation in final.c when building _fixunsdfdi is still present.
Build GCC with efence on Linux and it goes up in flames thusly:
./xgcc -B/usr/local/i686-pc-linux-gnu/bin/ -B./ -I/usr/local/i686-pc-linux-gnu/include -S tmp-dum.c
Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
xgcc: Internal compiler error: program cc1 got fatal signal 11
make: *** [s-under] Error 1
Core was generated by `./cc1 /tmp/ccQHXwtm.i -quiet -dumpbase tmp-dum.c -o tmp-dum.s'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0 0x80938d3 in plus_constant_wide (x=0x40216710, c=4)
at /play/egcs/gcc/explow.c:166
166 if (GET_CODE (XEXP (x, 1)) == CONST_INT)
Breakpoint 1 at 0x40039982: file exit.c, line 40.
Breakpoint 2 at 0x80ad0ba: file /play/egcs/gcc/rtl.c, line 1249.
Breakpoint 3 at 0x400387b8: file ../sysdeps/generic/abort.c, line 55.
(gdb) p /x *x
$1 = {code = 0x43, mode = 0x6, jump = 0x0, call = 0x0, unchanging = 0x0,
volatil = 0x0, in_struct = 0x0, used = 0x0, integrated = 0x0,
frame_related = 0x0, fld = {{rtwint = 0x40014080, rtint = 0x40014080,
rtstr = 0x40014080, rtx = 0x40014080, rtvec = 0x40014080,
rttype = 0x40014080, rt_addr_diff_vec_flags = {min_align = 0x80,
base_after_vec = 0x0, min_after_vec = 0x0, max_after_vec = 0x0,
min_after_base = 0x0, max_after_base = 0x0, offset_unsigned = 0x0, 0x1,
scale = 0x1}, rtbit = 0x40014080, rttree = 0x40014080,
bb = 0x40014080}}}
This is a new regression. This worked earlier in the week.
I'm about to give up trying to track this thing daily. There's just
too much crazy stuff going on. Yes, I know that nobody promised that
snapshots would always work, but there used to be a goal of keeping the
top-of-tree functional.
RJL