RV: gcc 2.95 bootstrap fail on OpenServer

[Robert Lipe]

> Such, I didn´t explain it very well. Compiler build is in stage1, gencodes
> is built using stage1 compiler, but when gencodes is run for stage1 I get a
> core dumped (signal 11).

Please cut and paste the context of the dump.  I still can't tell if
it's building stage1 or built using the stage1 compiler.   Also include
the info on the bootstrap compiler you're using.

> The crtbegin.o used to link gencodes had been built for stage1 gcc
> compiler. If I change crtbegin.o in gcc/stage1/crtbegin.o  by a previous
> gcc release, gencodes work fine. I guess this is a problem in crtstuff.c
> code with CRT_BEGIN preprocessor flags. This is init code in runtime in C

That's possible.  At least three others have reported results identical
to mine with 2.95 on 5.0.5 so we need to understand what's making your
environment different.   I don't know if your bootstrap compiler is toast,
if you're picking up some old library or just what.   I thinkt hat gencodes
just happens to have the misfortune of being the first program executed
by the freshly built tools...

> runtime environment. I was comparing crtbegin.s assembler code with
> previous releases and look some changes regarding to exception. This can be
> by a recent change to varasm.c?

Diffing disassemblies between 1.1.2 and 2.95 output is less fun than I'd
like to think we deserve at this point. 

> > What is your bootstrap compiler?  What flags were passed to configure?
> 
> I use configure --enable-languages="c c++", I am using SCO as.

What compiler was used to build stage1?   I, too, am using SCO as as it's
the most reasonable assembler to use on this target.

> > /src/tmp/gcc/xgcc -B/src/tmp/gcc/ -B/usr/local/i686-pc-sco3.2v5.0.5/bin/
> -c -g -O2 -fno-implicit-templates -I/play/egcs/libstdc++
> -I/play/egcs/libstdc++/stl -I../libio -I/play/egcs/libstdc++/../libio
> -nostdinc++  /play/egcs/libstdc++/valarray.cc
> > (EOF):undefined name: .L_T11459
> > (EOF):undefined name: .L_T2499
> > make[2]: *** [valarray.o] Error 1
> 
> I had seen this problem in previous release, but the assembled code such as
> generated for egcs is OK. I think this is assembler problem.

Look at the assembly code.  These are references to local labels that
aren't defined in that file.  It's a dwarf bug.

See also my response to Gabriel.

RJL