From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130393 invoked by alias); 8 Apr 2019 12:59:28 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 130385 invoked by uid 89); 8 Apr 2019 12:59:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:DmEw@ma, H*i:sk:DmEw@ma, H*F:U*law X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Apr 2019 12:59:26 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D26A630BB343; Mon, 8 Apr 2019 12:59:25 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-8.rdu2.redhat.com [10.10.112.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2B5763DA4; Mon, 8 Apr 2019 12:59:23 +0000 (UTC) Subject: Re: is re-running bootstrap after a change safe? To: Richard Biener , Martin Sebor Cc: Eric Botcazou , GCC Development References: <52db8781-a1f8-5fe1-7e05-ba3f984d9825@gmail.com> <2209859.RYDReTFH8C@polaris> From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Mon, 08 Apr 2019 12:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00116.txt.bz2 On 4/8/19 3:19 AM, Richard Biener wrote: > On Sat, Apr 6, 2019 at 1:09 AM Martin Sebor 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