From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8223 invoked by alias); 25 Feb 2020 10:36:30 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 8215 invoked by uid 89); 25 Feb 2020 10:36:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_PASS autolearn=ham version=3.3.1 spammy=dirty X-HELO: smtp.ispras.ru Received: from winnie.ispras.ru (HELO smtp.ispras.ru) (83.149.199.91) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 25 Feb 2020 10:36:19 +0000 Received: from [10.10.3.54] (utre4ko.intra.ispras.ru [10.10.3.54]) by smtp.ispras.ru (Postfix) with ESMTP id EB47A201D0; Tue, 25 Feb 2020 13:36:13 +0300 (MSK) Subject: Re: [PATCH] issues with configure --enable-checking option To: Jakub Jelinek Cc: Sandra Loosemore , "gcc-patches@gcc.gnu.org" , Richard Sandiford , Richard Biener , Alexander Monakov References: <540c7900-96e4-d762-56be-6b453a0a38a7@ispras.ru> <2f34ffaf-5038-01bd-4881-262a964e1820@ispras.ru> <7b5774a8-60d0-c36e-efde-8ff88755f50e@codesourcery.com> <20200225083042.GH2155@tucnak> From: Roman Zhuykov Message-ID: Date: Tue, 25 Feb 2020 10:36:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200225083042.GH2155@tucnak> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg01378.txt.bz2 Hi, Jakub! Jakub Jelinek writes: >> +When the option is not specified, the active set of checks depends on >> context. >> +Namely, bootstrap stage 1 defaults to @samp{--enable-checking=yes}, builds >> +from release archives default to @samp{--enable-checking=release}, and > Is archives the right word? The --enable-checking=release by default is > turned on whenever it is a release branch, checked by whether gcc/DEV-PHASE > is not experimental, and generally applies to everything but the GCC trunk. Not sure how to formulate it better, just "builds from release branch or release archives default to ..." ? Quoting myself: > Documentation issues (4): Statement "This is ‘yes,extra’ by default > when building from the source repository or snapshots." is wrong, > because 'snapshots' may relate to released branches (e.q. GCC > 9-20200125 Snapshot), and gcc/DEV-PHASE is empty there. > ... > Behavior issues (6): It is not obvious to have default > --enable-checking=release on any commit in releases/* branches > (DEV-PHASE is empty there). IMHO it's enough 'experimental' when > picking for example some commit between 9.1 and 9.2. This also can > confuse 'git bisect run' scenario when good revision is old enough and > bad revision is on release branch. I've started this thread with telling about a bit strange behavior and wrong documentation wording for release snapshots.  I was planing to ask again about behavior issues later when stage1 starts, certainly it can't be changed without slightly modifying some branching/release procedures.  AFAIR, after moving to git you have already posted some patch offering solution to drop DATESTAMP bumps using some git tricks.  We may also consider using other git tricks to check whether current commit is tagged and working copy is clean.  E.g. in qemu Makefile they have: # Create QEMU_PKGVERSION and FULL_VERSION strings # If PKGVERSION is set, use that; otherwise get version and -dirty status from git QEMU_PKGVERSION := $(if $(PKGVERSION),$(PKGVERSION),$(shell \   cd $(SRC_PATH); \   if test -e .git; then \     git describe --match 'v*' 2>/dev/null | tr -d '\n'; \     if ! git diff-index --quiet HEAD &>/dev/null; then \       echo "-dirty"; \     fi; \   fi)) If GCC would use an approach like this to extract version string, it can be extended for DEV-PHASE guessing. So, IMHO the best next step is to improve the behavior rather then docs :) >> +The @samp{valgrind} check requires the external @command{valgrind} >> simulator, >> +available from @uref{http://valgrind.org/}.  The @samp{df}, @samp{rtl}, >> +@samp{gcac} and @samp{valgrind} checks are very expensive. > I would certainly not say that rtl checking is very expensive Actually, that sentence wasn't changed in my patch, 'rtl' and 'gcac' are in that list since 2001. > it is somewhat expensive, but I'm using it in all my bootstraps and others are as > well. I forget all the time that I have to make the same practice. > So perhaps > > The @samp{rtl} checks are expensive and the @samp{df}, > @samp{fold}, @samp{gcac} and @samp{valgrind} checks are very expensive. > > ? Sure, I'm ready to update it in all active branches if we decide how to deal with "release branches/archives" above. Roman