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

["Bonzini Paolo" <paolo dot bonzini at lu dot unisi dot ch>]

	> make stage1-bubble STAGE1_LANGUAGES=c,c++,fortran,java 


> Wow, that's awkward.

I understand, but I have a patch to make it easier.
 
Patches for the toplevel take a long time to review, and I cannot handle posting too many patches and tracking them. Not even two patches. Currently I have a pending patch at http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00473.html that I would have liked to be in 4.1 too, so I am not sending out the changes that I have in my tree to make this easier.

However, the patch is not very twisty, and reviewing does not require thorough knowledge of cross compilation for example.  You are a GWP, so you could help.  A previous version of the patch is at http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00404.html but I've withdrawn it because I could make it even more similar to the old scheme.  If you want to review the newer version, I'll send it on monday and CC you.
 
Same goes for the documentation updates.
 
> Remind me why it's a good idea to force me to mess with bootstrapping
> at all, when all I want is to build a copy of the compiler that I can
> use for debugging problems?
 
First, because "make stage1-bubble" above only takes as much time as a non-bootstrapped build.  Is the command line harder than "make all-gcc; make -C gcc cc1plus f951 jc1"?  Maybe, but after the patch I mentioned above it will be the same as before toplevel bootstrap.
 
Second, because the toplevel bootstrap did fix bugs.  For example, the inability to bootstrap a 64-bit compiler with a 32-bit compiler (because libiberty was not built as a 64-bit binary) -- this requires a five line patch that was posted by Richard Guenther but has not been reviewed yet, either.  Or the binary compatibility problems when the compilation platform had a 4-byte bool. From the *user* point of view this is surely a progression.

Third, because nobody said it was a bad idea in the 16 months between the first (not the only) call for testing and the definitive enabling of toplevel bootstrap.

Fourth, because toplevel bootstrap is a prerequisite for many further cleanups and improvements, including moving libgcc to the toplevel and bootstrapping libada.

Eric Botcazou wrote:

> Glad to see that a GWP maintainer eventually speaks up. :-)

Well, Kenner is also GWP.  Still, it remains to be seen why the other did not speak up.  I am the first person that would like to know it.

> FWIW I personally think this toplevel bootstrap thing is a step backward, now 
> typing "make" triggers such a complex machinery that nobody seems to able to 
> understand what it does.

So the previous system was easy?  IMO it's just that it's been tested for 15 years.  Personally it took me a lot of time to understand the working of bubblestrap, stage*_copy, stage*_build, and so on

The point is that you have to decide in advance if the toplevel will bootstrap.  If you use --disable-bootstrap, it will not.  --disable-bootstrap will *not* disappear; rather, "../configure --disable-bootstrap && make bootstrap", which currently triggers the old-style GCC-only bootstrap, will disappear.

What I usually do, is developing in a --disable-bootstrap tree, and when I'm reasonably sure, start a fresh bootstrap (because I have a script that also does the comparison with a baseline run, and I let it run overnight).  In more complex cases, like debugging a miscompilation or otherwise failing bootstrap, I debug in a tree configured for bootstrap.

Paolo