Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)

[Paolo Bonzini]

Richard Kenner wrote:

>    From the user point of view it is a bad bug that you cannot bootstrap
>    a 64-bit compiler starting from a 32-bit one (because stage2 does not
>    find a 64-bit libiberty to use).
>
>To me, "bootstrap" means that all three compilers are identical in
>configuration, so I don't follow your example.
>  
>
In this case, the target is the same, but the machine is able to execute 
objects for more than one configuration.  build, host, and target all 
are for example powerpc64-linux, but the host compiler defaults to 
creating 32-bit objects and the bootstrapped compiler will default to 
creating 64-bit objects.

So the stage1 compiler is built as a 32-bit object, from the second 
stage on they're built as 64-bit objects.

>Since that's what I (and others, from the sound of it), need to do all the
>time, it sounds like we'll keep using --disable-bootstrap forever.
>  
>
Why can't you execute make bootstrap in the toplevel?

What I do is working on a fix in the stage1 directory, and then doing 
(depending on the kind of bug and fix) "make unstage1; make restrap" or 
"make bubblestrap".  With the new method they become respectively "cd .. 
&& make restrap", and "cd .. && make".  I re-bootstrap only when I 
expect things to go smoothly, at the *end* of the debugging.

Are you doing things differently?  (This is not kidding; maybe there's 
some fundamental misunderstanding).

Paolo