[Bug bootstrap/17817] [4.0 Regression] restage[1,2,3] and then bootstrap no longer cause build dir to be rebuilt

["dberlin at dberlin dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From dberlin at dberlin dot org  2004-10-04 17:01 -------
Subject: Re:  [4.0 Regression] restage[1,2,3] and then
	bootstrap no longer cause build dir to be rebuilt

On Mon, 2004-10-04 at 16:54 +0000, kcook at gcc dot gnu dot org wrote:
> ------- Additional Comments From kcook at gcc dot gnu dot org  2004-10-04 16:54 -------
> Subject: Re:  [4.0 Regression] restage[1,2,3] and then bootstrap no longer cause build dir to be rebuilt
> 
> I believe that this is currently working as intended.
> 
> The files in build/* are only built by the build compiler and do not
> get rebuilt between stages unless one of its dependendent source files
> changed.  The idea was to speed up bootstraps by not requiring the
> generator programs, some of which on some (*cough* darwin) platforms
> take a half hour to run, to be needlessly rerun multiple times only to
> produce identical output.  For a long winded explanation, see
> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00091.html.

Why not instead fix the programs to run faster?

> 
> In current CVS, the generator programs are no longer being rebuilt, yet
> they are still being rerun.  I have an, as yet unsubmitted, three line
> patch which would change the latter behavior to no longer erase the
> stamp files between stages for the generated files such as
> insn-attrtab.c.  I've been piecemealing the changes in, waiting a week
> or two for some negative feedback from the each piece, which you have
> now provided.
> 
> Do you have a specific example where the new behaviour you have noticed
> is causing a problem?
> 

The real problem is that if you are testing an optimization, and it
causes the generator programs to fail, you can no longer do

make restage1
<fix>
make bootstrap
and have it work, because it will no longer rebuild the generator 
programs with stage1, and will still try to run the broken programs.

I have to actually rm -rf build/* 
make restage1 (which rebuilds them now, and didn't before)
rm -rf build/*
make bootstrap
to get it to do what it used to.

This is somewhat of a pain in the ass to find and fix bugs that you
cause in the generator programs, which is not an uncommon occurrence
when testing new optimizations.

It'd be nice if there was at least some flag controlling this behavior
that i could set in configure or the makefile.


> Though I may be overlooking something, I'm under the impression that
> the benefits of a significantly quicker bootstrap will outweigh the
> risks of a missing a hypothetical bug in the stage2 compiler which
> causes a problem while generating our generated *.c files, yet not
> causing a bootstrap miscompare nor a problem overlooked by the
> testsuite.
I don't see why speeding up the gen* programs isn't an option here.  I
do see that they often produce identical output, and that this is
pointless.
I just wanted to register my complaint that something that used to be a
valuable source of testing (I've had entire optimizations have all their
bugs exposed by gengtype and genattrtab, so that when those two were
working, it bootstrapped and passed the entire testsuite on the first
try).

I guess i'll just do what i do now, or go to start running the testsuite
intsead of also relying upon reubilding generator programs to find bugs.


> 
> Also it is noteworthy that none of the behavior you are seeing will
> occur with the Paolo's top level bootstrap which I was under the
> impression was supposed to become the default RSN.
> 
Oh.

> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17817