Bootstrap failure on powerpc-linux

Bootstrap failure on powerpc-linux

[Daniel Jacobowitz]

The last snapshot fails to build libgcc2.a the first time (is that
stage1 or stage2?).  During _bb it runs out of virtual memory (at least
400MB worth).  I'll provide more information if anyone can tell me how
to.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|     CMU, CS class of 2002      |
|   Debian GNU/Linux Developer    __   Part-Time Systems Programmer  |
|         dan@debian.org         |  |        drow@cs.cmu.edu         |
\--------------------------------/  \--------------------------------/

Re: Bootstrap failure on powerpc-linux

[Daniel Jacobowitz]

On Sun, Jan 24, 1999 at 10:57:33PM -0500, Zack Weinberg wrote:
> On Sun, 24 Jan 1999 21:18:48 -0500, Daniel Jacobowitz wrote:
> >The last snapshot fails to build libgcc2.a the first time (is that
> >stage1 or stage2?).  During _bb it runs out of virtual memory (at least
> >400MB worth).  I'll provide more information if anyone can tell me how
> >to.
> 
> As a start, figure out the command to make _bb, stick a -Q in there,
> and see which pass is blowing up.
> 
> zw

The last function printed is __bb_exit_trae_func:

2.1:/usr/src/egcs/egcs-snapshot-19990124/builddir/gcc$   ./xgcc -B./  \
  -B/usr/powerpc-linux/bin/ -O2 -DIN_GCC -DHAIFA -DMULTIBYTE_CHARS=1  \
  -g -W -Wall -I./include  -fPIC -g1 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 \
  -D__GCC_FLOAT_NOT_NEEDED    -mstrict-align -I. -I../../gcc          \
  -I../../gcc/config -I../../gcc/../include -c -DL_bb                 \
  ../../gcc/libgcc2.c -Q -o _bb.o
../../gcc/libgcc2.c:0: warning: `#system(unix)' re-asserted
../../gcc/libgcc2.c:0: warning: `#system(linux)' re-asserted
 strtod strtol strtoul strtoq strtouq strtoll strtoull atof atoi atol
 atoll vprintf getchar getc_unlocked getchar_unlocked putchar
 fputc_unlocked putc_unlocked putchar_unlocked feof_unlocked
 ferror_unlocked __store_long __fetch_long __write_long __read_long
 __strcpy_small __strcspn_c1 __strcspn_c2 __strcspn_c3 __strspn_c1
 __strspn_c2 __strspn_c3 __strpbrk_c2 __strpbrk_c3 __strtok_r_1c
 __strsep_1c __strsep_2c __strsep_3c __strsep_g num_digits
 __bb_exit_func
../../gcc/libgcc2.c: In function \x1f_bb_exit_func':
../../gcc/libgcc2.c:1603: warning: implicit declaration of function `time'
../../gcc/libgcc2.c:1613: warning: comparison between signed and unsigned
../../gcc/libgcc2.c:1641: warning: comparison between signed and unsigned
 __bb_init_func __bb_exit_trace_func

and then it hangs and spins.

Any other debugging options I should try?  And BTW, -Q is nearly
completely undocumented.  It is mentioned once in the info page, but
not in the listing of arguments; it is completely absent from the man
page.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|     CMU, CS class of 2002      |
|   Debian GNU/Linux Developer    __   Part-Time Systems Programmer  |
|         dan@debian.org         |  |        drow@cs.cmu.edu         |
\--------------------------------/  \--------------------------------/

Re: Bootstrap failure on powerpc-linux

[Daniel Jacobowitz]

On Sun, Jan 24, 1999 at 10:57:33PM -0500, Zack Weinberg wrote:
> On Sun, 24 Jan 1999 21:18:48 -0500, Daniel Jacobowitz wrote:
> >The last snapshot fails to build libgcc2.a the first time (is that
> >stage1 or stage2?).  During _bb it runs out of virtual memory (at least
> >400MB worth).  I'll provide more information if anyone can tell me how
> >to.
> 
> As a start, figure out the command to make _bb, stick a -Q in there,
> and see which pass is blowing up.


OK, here's a test case.  I'm going to go back and look, but I'm
assuming someone made a careless error in a change to the parser
recently - this looks to me like a signedness error causing an infinite
loop.  There are a LOT of signed vs. unsigned comparisons left on
powerpc.

void __bb_exit_trace_func ()
{
  (void)("\tF");
}


A \t in a constant string, followed by any letter, causes the parser to
loop and eat memory infinitely.  This is current mainline for the past
two days.



Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|     CMU, CS class of 2002      |
|   Debian GNU/Linux Developer    __   Part-Time Systems Programmer  |
|         dan@debian.org         |  |        drow@cs.cmu.edu         |
\--------------------------------/  \--------------------------------/

Re: Bootstrap failure on powerpc-linux

[Zack Weinberg]

On Mon, 25 Jan 1999 13:45:29 -0500, Daniel Jacobowitz wrote:
>On Sun, Jan 24, 1999 at 10:57:33PM -0500, Zack Weinberg wrote:
>> On Sun, 24 Jan 1999 21:18:48 -0500, Daniel Jacobowitz wrote:
>> >The last snapshot fails to build libgcc2.a the first time (is that
>> >stage1 or stage2?).  During _bb it runs out of virtual memory (at least
>> >400MB worth).  I'll provide more information if anyone can tell me how
>> >to.
>> 
>> As a start, figure out the command to make _bb, stick a -Q in there,
>> and see which pass is blowing up.
>
>
>OK, here's a test case.  I'm going to go back and look, but I'm
>assuming someone made a careless error in a change to the parser
>recently - this looks to me like a signedness error causing an infinite
>loop.  There are a LOT of signed vs. unsigned comparisons left on
>powerpc.
>
>void __bb_exit_trace_func ()
>{
>  (void)("\tF");
>}
>
>
>A \t in a constant string, followed by any letter, causes the parser to
>loop and eat memory infinitely.  This is current mainline for the past
>two days.

Don't just tell me about it - I haven't a chance of finding a parser
bug, especially without a powerpc to poke at.

Can someone with half a clue about the parser shed some light?

zw

Re: Bootstrap failure on powerpc-linux

[Daniel Jacobowitz]

I've located the problem.

Multibyte character support has a nasty bug with escape sequences,
around line 2064 of gcc/c-lex.c.  I can't quite figure out why/how this
happens, but the character immediately after an escape sequence (say,
"\n") is reported as a char_len == 0.  Because char_len <= i (also 0),
the character is stuffed back on the stack.  It is then popped off four
lines later, and the loop continues.  That character gets tiled through
memory until the compiler crashes.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|     CMU, CS class of 2002      |
|   Debian GNU/Linux Developer    __   Part-Time Systems Programmer  |
|         dan@debian.org         |  |        drow@cs.cmu.edu         |
\--------------------------------/  \--------------------------------/