is re-running bootstrap after a change safe?

is re-running bootstrap after a change safe?

[Martin Sebor]

Is it safe to rerun make bootstrap after changing GCC source?

Say if the first bootstrap succeeds and I then change a single
GCC .c file and rerun make bootstrap, am I guaranteed to see
the same fallout of the change as I would if I did a pristine
build in a clean directory?

I have been assuming this is safe and so after each tweak to
a patch I work on I rerun make bootstrap in the same build
directory.  It can speed things up quite a bit.

But the recent bootstrap breakage (PR 89980) makes me wonder
if it is, in fact, safe.  I can see the broken bootstrap today
in a clean build yet the bootstrap I did just before checking
in the change went fine.

Martin

Re: is re-running bootstrap after a change safe?

[H.J. Lu]

On Fri, Apr 5, 2019 at 12:55 PM Martin Sebor <msebor@gmail.com> wrote:
>
> Is it safe to rerun make bootstrap after changing GCC source?
>
> Say if the first bootstrap succeeds and I then change a single
> GCC .c file and rerun make bootstrap, am I guaranteed to see
> the same fallout of the change as I would if I did a pristine
> build in a clean directory?
>
> I have been assuming this is safe and so after each tweak to
> a patch I work on I rerun make bootstrap in the same build
> directory.  It can speed things up quite a bit.
>
> But the recent bootstrap breakage (PR 89980) makes me wonder
> if it is, in fact, safe.  I can see the broken bootstrap today
> in a clean build yet the bootstrap I did just before checking
> in the change went fine.
>

You need to do a clean bootstrap.

-- 
H.J.

Re: is re-running bootstrap after a change safe?

[Eric Botcazou]

> Say if the first bootstrap succeeds and I then change a single
> GCC .c file and rerun make bootstrap, am I guaranteed to see
> the same fallout of the change as I would if I did a pristine
> build in a clean directory?

No, this would imply deleting the stage2 and stage3 compilers and that isn't 
what happens.  Instead the compiler of each stage is updated in isolation.

-- 
Eric Botcazou

Re: is re-running bootstrap after a change safe?

[Jeff Law]

On 4/5/19 2:50 PM, Eric Botcazou wrote:
>> Say if the first bootstrap succeeds and I then change a single
>> GCC .c file and rerun make bootstrap, am I guaranteed to see
>> the same fallout of the change as I would if I did a pristine
>> build in a clean directory?
> 
> No, this would imply deleting the stage2 and stage3 compilers and that isn't 
> what happens.  Instead the compiler of each stage is updated in isolation.
> 
RIght.  Thus I always blow away stage2-* stage3-*, and stage1 target
directories along with the "compare" stamp file.

Jeff

Re: is re-running bootstrap after a change safe?

[Martin Sebor]

On 4/5/19 3:29 PM, Jeff Law wrote:
> On 4/5/19 2:50 PM, Eric Botcazou wrote:
>>> Say if the first bootstrap succeeds and I then change a single
>>> GCC .c file and rerun make bootstrap, am I guaranteed to see
>>> the same fallout of the change as I would if I did a pristine
>>> build in a clean directory?
>>
>> No, this would imply deleting the stage2 and stage3 compilers and that isn't
>> what happens.  Instead the compiler of each stage is updated in isolation.
>>
> RIght.  Thus I always blow away stage2-* stage3-*, and stage1 target
> directories along with the "compare" stamp file.

Thanks (all of you).  It's amazing that I have been getting away
with it for all these years.

Why is this not done automatically?  I mean, what is the use case
for make bootstrap without doing these steps first?

Martin

Re: is re-running bootstrap after a change safe?

[Jeff Law]

On 4/5/19 3:37 PM, Martin Sebor wrote:
> On 4/5/19 3:29 PM, Jeff Law wrote:
>> On 4/5/19 2:50 PM, Eric Botcazou wrote:
>>>> Say if the first bootstrap succeeds and I then change a single
>>>> GCC .c file and rerun make bootstrap, am I guaranteed to see
>>>> the same fallout of the change as I would if I did a pristine
>>>> build in a clean directory?
>>>
>>> No, this would imply deleting the stage2 and stage3 compilers and
>>> that isn't
>>> what happens.  Instead the compiler of each stage is updated in
>>> isolation.
>>>
>> RIght.  Thus I always blow away stage2-* stage3-*, and stage1 target
>> directories along with the "compare" stamp file.
> 
> Thanks (all of you).  It's amazing that I have been getting away
> with it for all these years.
I got away without removing the "compare" stamp file for a long time,
then broke the trunk with a comparison failure :(

> 
> Why is this not done automatically?  I mean, what is the use case
> for make bootstrap without doing these steps first?
During development folks often want to rebuild without going through a
full bootstrap.  Obviously for testing the final version of a patch the
"quick" approach of just rebuilding without blowing away the stage
directories isn't sufficient.

This is actually one of the things I'd really like to just automate.
You point to a git commit in a public repo, the tester picks it up and
does a bootstrap & regression test from scratch on whatever targets you
ask for.

jeff

Re: is re-running bootstrap after a change safe?

[Martin Sebor]

On 4/5/19 4:02 PM, Jeff Law wrote:
> On 4/5/19 3:37 PM, Martin Sebor wrote:
>> On 4/5/19 3:29 PM, Jeff Law wrote:
>>> On 4/5/19 2:50 PM, Eric Botcazou wrote:
>>>>> Say if the first bootstrap succeeds and I then change a single
>>>>> GCC .c file and rerun make bootstrap, am I guaranteed to see
>>>>> the same fallout of the change as I would if I did a pristine
>>>>> build in a clean directory?
>>>>
>>>> No, this would imply deleting the stage2 and stage3 compilers and
>>>> that isn't
>>>> what happens.  Instead the compiler of each stage is updated in
>>>> isolation.
>>>>
>>> RIght.  Thus I always blow away stage2-* stage3-*, and stage1 target
>>> directories along with the "compare" stamp file.
>>
>> Thanks (all of you).  It's amazing that I have been getting away
>> with it for all these years.
> I got away without removing the "compare" stamp file for a long time,
> then broke the trunk with a comparison failure :(
> 
>>
>> Why is this not done automatically?  I mean, what is the use case
>> for make bootstrap without doing these steps first?
> During development folks often want to rebuild without going through a
> full bootstrap.  Obviously for testing the final version of a patch the
> "quick" approach of just rebuilding without blowing away the stage
> directories isn't sufficient.

I see.  So after a bootstrap and a subsequent change to a .c file,
at each stage the next bootstrap recompiles just the changed file
and relinks gcc.  It doesn't actually recompile all source files
in stage 2 or 3 with the changed compiler from the last stage.
That's why it's so much faster!  Make check then correctly reflects
the change but the compiler doesn't get as fully exercised because
the test suite has low coverage.

> This is actually one of the things I'd really like to just automate.
> You point to a git commit in a public repo, the tester picks it up and
> does a bootstrap & regression test from scratch on whatever targets you
> ask for.

That would be great to validate the final patch.

So to be clear: the safe and also most efficient to "rebootstrap"
GCC is to remove what exactly?  (I don't see any stage2 or stage3
directories in my build tree.)  Is there a make target for this?

Thanks
Martin

Re: is re-running bootstrap after a change safe?

[Andreas Schwab]

On Apr 05 2019, Martin Sebor <msebor@gmail.com> wrote:

> So to be clear: the safe and also most efficient to "rebootstrap"
> GCC is to remove what exactly?  (I don't see any stage2 or stage3
> directories in my build tree.)  Is there a make target for this?

make stage1-start; rm -rf stage[23]-* compare

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: is re-running bootstrap after a change safe?

[Richard Biener]

On Sat, Apr 6, 2019 at 1:09 AM Martin Sebor <msebor@gmail.com> wrote:
>
> On 4/5/19 4:02 PM, Jeff Law wrote:
> > On 4/5/19 3:37 PM, Martin Sebor wrote:
> >> On 4/5/19 3:29 PM, Jeff Law wrote:
> >>> On 4/5/19 2:50 PM, Eric Botcazou wrote:
> >>>>> Say if the first bootstrap succeeds and I then change a single
> >>>>> GCC .c file and rerun make bootstrap, am I guaranteed to see
> >>>>> the same fallout of the change as I would if I did a pristine
> >>>>> build in a clean directory?
> >>>>
> >>>> No, this would imply deleting the stage2 and stage3 compilers and
> >>>> that isn't
> >>>> what happens.  Instead the compiler of each stage is updated in
> >>>> isolation.
> >>>>
> >>> RIght.  Thus I always blow away stage2-* stage3-*, and stage1 target
> >>> directories along with the "compare" stamp file.
> >>
> >> Thanks (all of you).  It's amazing that I have been getting away
> >> with it for all these years.
> > I got away without removing the "compare" stamp file for a long time,
> > then broke the trunk with a comparison failure :(
> >
> >>
> >> Why is this not done automatically?  I mean, what is the use case
> >> for make bootstrap without doing these steps first?
> > During development folks often want to rebuild without going through a
> > full bootstrap.  Obviously for testing the final version of a patch the
> > "quick" approach of just rebuilding without blowing away the stage
> > directories isn't sufficient.
>
> I see.  So after a bootstrap and a subsequent change to a .c file,
> at each stage the next bootstrap recompiles just the changed file
> and relinks gcc.  It doesn't actually recompile all source files
> in stage 2 or 3 with the changed compiler from the last stage.
> That's why it's so much faster!  Make check then correctly reflects
> the change but the compiler doesn't get as fully exercised because
> the test suite has low coverage.
>
> > This is actually one of the things I'd really like to just automate.
> > You point to a git commit in a public repo, the tester picks it up and
> > does a bootstrap & regression test from scratch on whatever targets you
> > ask for.
>
> That would be great to validate the final patch.
>
> So to be clear: the safe and also most efficient to "rebootstrap"
> GCC is to remove what exactly?

Just remove everything?  Toplevel configure and stage1 build is
fast anyway.

That's what I'm doing since forever.

Richard.

>  (I don't see any stage2 or stage3
> directories in my build tree.)  Is there a make target for this?
>
> Thanks
> Martin

Re: is re-running bootstrap after a change safe?

[Jeff Law]

On 4/8/19 3:19 AM, Richard Biener wrote:
> On Sat, Apr 6, 2019 at 1:09 AM Martin Sebor <msebor@gmail.com> wrote:
>>
>> On 4/5/19 4:02 PM, Jeff Law wrote:
>>> On 4/5/19 3:37 PM, Martin Sebor wrote:
>>>> On 4/5/19 3:29 PM, Jeff Law wrote:
>>>>> On 4/5/19 2:50 PM, Eric Botcazou wrote:
>>>>>>> Say if the first bootstrap succeeds and I then change a single
>>>>>>> GCC .c file and rerun make bootstrap, am I guaranteed to see
>>>>>>> the same fallout of the change as I would if I did a pristine
>>>>>>> build in a clean directory?
>>>>>>
>>>>>> No, this would imply deleting the stage2 and stage3 compilers and
>>>>>> that isn't
>>>>>> what happens.  Instead the compiler of each stage is updated in
>>>>>> isolation.
>>>>>>
>>>>> RIght.  Thus I always blow away stage2-* stage3-*, and stage1 target
>>>>> directories along with the "compare" stamp file.
>>>>
>>>> Thanks (all of you).  It's amazing that I have been getting away
>>>> with it for all these years.
>>> I got away without removing the "compare" stamp file for a long time,
>>> then broke the trunk with a comparison failure :(
>>>
>>>>
>>>> Why is this not done automatically?  I mean, what is the use case
>>>> for make bootstrap without doing these steps first?
>>> During development folks often want to rebuild without going through a
>>> full bootstrap.  Obviously for testing the final version of a patch the
>>> "quick" approach of just rebuilding without blowing away the stage
>>> directories isn't sufficient.
>>
>> I see.  So after a bootstrap and a subsequent change to a .c file,
>> at each stage the next bootstrap recompiles just the changed file
>> and relinks gcc.  It doesn't actually recompile all source files
>> in stage 2 or 3 with the changed compiler from the last stage.
>> That's why it's so much faster!  Make check then correctly reflects
>> the change but the compiler doesn't get as fully exercised because
>> the test suite has low coverage.
>>
>>> This is actually one of the things I'd really like to just automate.
>>> You point to a git commit in a public repo, the tester picks it up and
>>> does a bootstrap & regression test from scratch on whatever targets you
>>> ask for.
>>
>> That would be great to validate the final patch.
>>
>> So to be clear: the safe and also most efficient to "rebootstrap"
>> GCC is to remove what exactly?
> 
> Just remove everything?  Toplevel configure and stage1 build is
> fast anyway.
> 
> That's what I'm doing since forever.
I suspect it's very fast if ccache is set up :-)  What's left for the
stage1 build would be all the configury gunk.

jeff