IA32 breakage. Was: Fix for build failure on Intel is now available

[Robert Lipe <robertlipe at usa dot net>]

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