egcs-1998-06-12: bootstrap failure

[Craig Burley]

>stage1/xgcc -Bstage1/ -c  -DIN_GCC    -W -Wall -O2 -g -O2   
>-DHAVE_CONFIG_H     -I. -I../../egcs/gcc -I../../egcs/gcc/config  
>../../egcs/gcc/c-lex.c
>../../egcs/gcc/c-gperf.h: In function `hash':
>In file included from ../../egcs/gcc/c-lex.c:130:
>../../egcs/gcc/c-gperf.h:43: warning: array subscript has type `char'
>../../egcs/gcc/c-gperf.h:46: warning: array subscript has type `char'
>../../egcs/gcc/c-gperf.h:49: warning: array subscript has type `char'
>../../egcs/gcc/c-lex.c: In function `check_newline':
>../../egcs/gcc/c-lex.c:546: warning: implicit declaration of  
>function `handle_pragma'
>../../egcs/gcc/c-lex.c: In function `readescape':
>../../egcs/gcc/c-lex.c:923: warning: comparison between signed and  
>unsigned
>../../egcs/gcc/c-lex.c: In function `yylex':
>../../egcs/gcc/c-lex.c:1490: warning: implicit declaration of  
>function `set_float_handler'
>../../egcs/gcc/c-lex.c:1823: warning: comparison between signed and  
>unsigned
>../../egcs/gcc/c-lex.c:1054: warning: variable `c' might be  
>clobbered by `longjmp' or `vfork'
>../../egcs/gcc/c-lex.c:1055: warning: variable `p' might be  
>clobbered by `longjmp' or `vfork'
>../../egcs/gcc/c-lex.c:1443: warning: variable `type' might be  
>clobbered by `longjmp' or `vfork'
>../../egcs/gcc/c-lex.c:1444: warning: variable `imag' might be  
>clobbered by `longjmp' or `vfork'
>../../egcs/gcc/c-lex.c:1445: warning: variable `conversion_errno'  
>might be clobbered by `longjmp' or `vfork'
>../../egcs/gcc/global.c:401: Internal compiler error in function  
>global_alloc
>make[2]: *** [c-lex.o] Error 1
>
>Note that the error message reports the source file as  
>`../../egcs/gcc/global.c', which is completely bogus, as the compile  
>line above clearly shows that the file being compiled is c-lex.c.
>
>Something very fishy is going on here.

Is it at all possible the stderr output you're seeing is "beating"
the stdout output showing the new compile line?  Or that somehow
you're seeing a strange flushing behavior?

Seems unlikely, given how much later global.c normally is compiled
after c-lex.c, and that make still reports an error occurring
for the c-lex.o target.  (I wonder whether that report is to
stdout or stderr?)

So, another possibility might be I/O error or similar, affecting
any of: the relevant Makefile (c-lex.o fragment, for example);
the compiler itself; the preprocessor; the OS; etc.

        tq vm, (burley)