From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90605 invoked by alias); 29 Jan 2020 13:32:51 -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 90597 invoked by uid 89); 29 Jan 2020 13:32:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_2,GIT_PATCH_3,HTML_MESSAGE,SPF_PASS autolearn=ham version=3.3.1 spammy=relate, categories, IMHO, imho 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; Wed, 29 Jan 2020 13:32:48 +0000 Received: from [10.10.3.54] (utre4ko.intra.ispras.ru [10.10.3.54]) by smtp.ispras.ru (Postfix) with ESMTP id CF436203C9 for ; Wed, 29 Jan 2020 16:32:45 +0300 (MSK) From: Roman Zhuykov Subject: [PATCH] issues with configure --enable-checking option To: "gcc-patches@gcc.gnu.org" Message-ID: <540c7900-96e4-d762-56be-6b453a0a38a7@ispras.ru> Date: Wed, 29 Jan 2020 13:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg01936.txt.bz2 Hi! I've investigated a bit, because some of the following confused me while working with some local 9.2-based branch. Documentation issues: (0) See patch for install.texi at the bottom, two possible values are not documented. Ok for master? Backports? (1) For me it seems confusing to have 'tree' and 'gimple' values, but not sure how to solve this. (2) Developer has to look into configure scripts to understand which macro will be defined. E.q. 'misc' means "CHECKING_P". (3) Install.texi IMHO doesn't properly describe what happens when --enable-checking is used without "=list". Maybe we should explicitly tell this means same as "=yes". (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. (5) Statement "‘extra’ adds for ‘misc’ checking extra checks ..." is also confusing, one can run 'configure --enable-checking=extra' and will have only ENABLE_EXTRA_CHECKING, but not CHECKING_P, and in common.opt flag_checking will have Init(0). 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. See also (4). (7) Running "configure --enable-checking" means less (!) checks on master branch (where DEV-PHASE is experimental). Default is "yes+extra" and you get only "yes" with that option. (8) Why we always start with "release" values ('assert'+'runtime') as default? If developer runs "configure --enable-checking=df,rtl,tree" probably it should mean only picked values are enabled. Why we silently add 'assert' and 'runtime' into that set? I haven't tried to find additional issues with related '--enable-stage1-checking' option. Roman PS. I see some lines have more than 80 chars in install.texi, few of them were added recently while cleaning references to SVN. Patch fixes this only forthe paragraph it touches. -- gcc/ChangeLog: 2020-01-29  Roman Zhuykov     * doc/install.texi: Document 'types' and 'gimple' values for     '--enable-checking' configure option. diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi --- a/gcc/doc/install.texi +++ b/gcc/doc/install.texi @@ -1845,19 +1845,19 @@ consistency checks of the requested complexity.  This does not change the  generated code, but adds error checking within the compiler.  This will  slow down the compiler and may only work properly if you are building  the compiler with GCC@.  This is @samp{yes,extra} by default when building -from the source repository or snapshots, but @samp{release} for releases.  The default -for building the stage1 compiler is @samp{yes}.  More control +from the source repository or snapshots, but @samp{release} for releases. +The default for building the stage1 compiler is @samp{yes}.  More control  over the checks may be had by specifying @var{list}.  The categories of  checks available are @samp{yes} (most common checks -@samp{assert,misc,tree,gc,rtlflag,runtime}), @samp{no} (no checks at -all), @samp{all} (all but @samp{valgrind}), @samp{release} (cheapest +@samp{assert,misc,tree,gc,gimple,rtlflag,runtime,types}), @samp{no} (no checks +at all), @samp{all} (all but @samp{valgrind}), @samp{release} (cheapest  checks @samp{assert,runtime}) or @samp{none} (same as @samp{no}).  Individual checks can be enabled with these flags @samp{assert}, -@samp{df}, @samp{fold}, @samp{gc}, @samp{gcac}, @samp{misc}, @samp{rtl}, -@samp{rtlflag}, @samp{runtime}, @samp{tree}, @samp{extra} and @samp{valgrind}. -@samp{extra} adds for @samp{misc} checking extra checks that might affect -code generation and should therefore not differ between stage1 and later -stages. +@samp{df}, @samp{fold}, @samp{gc}, @samp{gcac}, @samp{gimple}, @samp{misc}, +@samp{rtl}, @samp{rtlflag}, @samp{runtime}, @samp{tree}, @samp{types}, +@samp{extra} and @samp{valgrind}. @samp{extra} adds for @samp{misc} checking +extra checks that might affect code generation and should therefore not differ +between stage1 and later stages.  The @samp{valgrind} check requires the external @command{valgrind}  simulator, available from @uref{http://valgrind.org/}.  The