At last: the bool problem seems to be due to omitted dependency from make check*

At last: the bool problem seems to be due to omitted dependency from make check*

[Tim Josling]

I have been trying to solve this problem for 18 months...

If you do the following steps

1. bootstrap.
2. Do not do make install, and do not have the install directory in your path.
3. Amend toplev.c or Makefile.in.
4. make check.

the make check will force recompilation of several modules using the standard
(host/bootstrap) cc, not the just built gcc. 

This has a number of untoward effects:

File toplev.c gets recompiled with a different size definition of bool than
diagnostic.c got during the bootstrap (on gnu/linux 2.4 anyway). This creates
a misalignment in the error diagnostics struct, as a result of which, warnings
result in an error exit when the resulting compiler is used. Sometimes, GCC
gets used for things other than building GCC.

The bootstrap compiler may not be able to run the compile for various reasons,
such as unsupported options. 

I'm not sure what the solution is. The install.texi documentation suggests
that testing should be done before installation, so I assume that I am not
expected to have installed GCC before a make check. This is consistent with
the checks themselves which seem to use the './xgcc' compiler from the build.

My suggestion would be to make the check* dependent on quickstrap, to force a
proper recompilation.

Tim Josling

Re: At last: the bool problem seems to be due to omitted dependency from make check*

[Joseph S. Myers]

On Sat, 1 Mar 2003, Tim Josling wrote:

> File toplev.c gets recompiled with a different size definition of bool than

I have previously suggested
<http://gcc.gnu.org/ml/gcc/2002-09/msg00797.html> that we should avoid
this problem simply by not using the system <stdbool.h>.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: At last: the bool problem seems to be due to omitted dependencyfrom make check*

[Tim Josling]

The problem I had in this case was that the system cc didn't like -fstats so
it failed. To me, the stdbool only seems to solve part of the problem, which
is that suddenly we are building part of the compiler with a wrong compiler.
How would this work with C++?

Tim Josling


"Joseph S. Myers" wrote:
> 
> On Sat, 1 Mar 2003, Tim Josling wrote:
> 
> > File toplev.c gets recompiled with a different size definition of bool than
> 
> I have previously suggested
> <http://gcc.gnu.org/ml/gcc/2002-09/msg00797.html> that we should avoid
> this problem simply by not using the system <stdbool.h>.
> 
> --
> Joseph S. Myers
> jsm28@cam.ac.uk

Re: At last: the bool problem seems to be due to omitted dependencyfrom make check*

[Joseph S. Myers]

On Sat, 1 Mar 2003, Tim Josling wrote:

> The problem I had in this case was that the system cc didn't like -fstats so
> it failed. To me, the stdbool only seems to solve part of the problem, which
> is that suddenly we are building part of the compiler with a wrong compiler.
> How would this work with C++?

Both problems should be solved, but the dependency one is intrinsically
hard to solve.  After all, if you change toplev.c, it should first rebuild
to stage1 toplev.o with the bootstrap compiler, then relink the stage1
compiler, then rebuild stage2 and stage3, if the dependencies are properly
correct.  Properly correct dependencies should mean exposing all
dependencies, between all stages, to one invocation of make, but this
can't work because each stage needs to be built separately, with the files
in the same location (not in the stage subdirectory), for the compare
stage to succeed.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: At last: the bool problem seems to be due to omitted dependencyfrommake check*

[Tim Josling]

"Joseph S. Myers" wrote:
> 
> On Sat, 1 Mar 2003, Tim Josling wrote:
> 
> > The problem I had in this case was that the system cc didn't like -fstats so
> > it failed. To me, the stdbool only seems to solve part of the problem, which
> > is that suddenly we are building part of the compiler with a wrong compiler.
> > How would this work with C++?
> 
> Both problems should be solved, but the dependency one is intrinsically
> hard to solve.  After all, if you change toplev.c, it should first rebuild
> to stage1 toplev.o with the bootstrap compiler, then relink the stage1
> compiler, then rebuild stage2 and stage3, if the dependencies are properly
> correct.  Properly correct dependencies should mean exposing all
> dependencies, between all stages, to one invocation of make, but this
> can't work because each stage needs to be built separately, with the files
> in the same location (not in the stage subdirectory), for the compare
> stage to succeed.
> 
> --
> Joseph S. Myers
> jsm28@cam.ac.uk

It looks like this is not going to get fixed. How about a patch to the
install.texi to at least warn people "make sure your build is up to date, e.g.
by make quickstrap, before starting any tests"?

Tim Josling

Re: At last: the bool problem seems to be due to omitted dependencyfrom make check*

[Fergus Henderson]

On 01-Mar-2003, Joseph S. Myers <jsm28@cam.ac.uk> wrote:
> On Sat, 1 Mar 2003, Tim Josling wrote:
> 
> > The problem I had in this case was that the system cc didn't like -fstats so
> > it failed. To me, the stdbool only seems to solve part of the problem, which
> > is that suddenly we are building part of the compiler with a wrong compiler.
> > How would this work with C++?
> 
> Both problems should be solved, but the dependency one is intrinsically
> hard to solve.  After all, if you change toplev.c, it should first rebuild
> to stage1 toplev.o with the bootstrap compiler, then relink the stage1
> compiler, then rebuild stage2 and stage3, if the dependencies are properly
> correct.

Isn't that what "make bubblestrap" is for?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: At last: the bool problem seems to be due to omitted dependencyfrom make check*

[Joseph S. Myers]

On Mon, 3 Mar 2003, Fergus Henderson wrote:

> > Both problems should be solved, but the dependency one is intrinsically
> > hard to solve.  After all, if you change toplev.c, it should first rebuild
> > to stage1 toplev.o with the bootstrap compiler, then relink the stage1
> > compiler, then rebuild stage2 and stage3, if the dependencies are properly
> > correct.
> 
> Isn't that what "make bubblestrap" is for?

Perhaps then that's what the testsuite rules should depend on to fix the
immediate problem, but ideally you wouldn't need special rules like that;  
the testsuite rules would just depend on "all" (compiler and libraries
built) which would depend on the specific executables and libraries used,
and the rules and dependencies would handle the bootstrap automatically
without the need for moving files around.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: At last: the bool problem seems to be due to omitted dependencyfrom make check*

[Michael S. Zick]

On Monday 03 March 2003 03:13 am, Joseph S. Myers wrote:
> On Mon, 3 Mar 2003, Fergus Henderson wrote:
> > > Both problems should be solved, but the dependency one is intrinsically
> > > hard to solve.  After all, if you change toplev.c, it should first
> > > rebuild to stage1 toplev.o with the bootstrap compiler, then relink the
> > > stage1 compiler, then rebuild stage2 and stage3, if the dependencies
> > > are properly correct.
> >
> > Isn't that what "make bubblestrap" is for?
>
> Perhaps then that's what the testsuite rules should depend on to fix the
> immediate problem, but ideally you wouldn't need special rules like that;
> the testsuite rules would just depend on "all" (compiler and libraries
> built) which would depend on the specific executables and libraries used,
> and the rules and dependencies would handle the bootstrap automatically
> without the need for moving files around.

Perhaps a RFA for the testsuite...

Is there a way to put notations into each testsuite test entry that:
1) to the testsuite look like comments (no effect on tests)
2) lists the source files that where touched when the problem a
test is checking for was (last) corrected.  

This would provide a lead into finding the problem when that
test begins to fail in the future.

Mike

Re: At last: the bool problem seems to be due to omitted dependency from make check*

[Mike Stump]

On Saturday, March 1, 2003, at 02:48 AM, Joseph S. Myers wrote:
> On Sat, 1 Mar 2003, Tim Josling wrote:
>
>> File toplev.c gets recompiled with a different size definition of 
>> bool than
>
> I have previously suggested
> <http://gcc.gnu.org/ml/gcc/2002-09/msg00797.html> that we should avoid
> this problem simply by not using the system <stdbool.h>.

I think we should just recommend that developers (they know who they 
are) must use gcc 3.x (or whatever version will work) or later to 
build.  I know, seems obscure and wrong, but sometimes life is too 
short.  I don't like gcc_bool very much, seems a step in the wrong 
direction.  I don't want a dependancy on quickstrap for testing either. 
  So, the question is, would be be so bad if we just recommended 
versions later than X for developers?  Does this actually solve the 
problem?  Certainly the requirement for contrib/update_gcc or autoconf 
2.13 is more obscure and has been a larger headache over the years?

Re: At last: the bool problem seems to be due to omitted dependencyfrom make check*

[DJ Delorie]

> > Isn't that what "make bubblestrap" is for?
> 
> Perhaps then that's what the testsuite rules should depend on to fix the
> immediate problem,

"make bubblestrap" doesn't work if you didn't "make bootstrap" to
begin with.  And a bubblestrap can be pretty resource intensive in
some cases.

IMHO "make check" is a pseudo-target that shouldn't be building
ANYTHING.  At best, it could fail if the needed bits hadn't been built
yet, but since it's difficult to auto-detect how the current build was
built (all vs bootstrap vs hand-tweaked stuff while debugging) perhaps
it shouldn't try.