On 4/8/19 3:19 AM, Richard Biener wrote: > On Sat, Apr 6, 2019 at 1:09 AM Martin Sebor <mse...@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
