From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.ispras.ru (winnie.ispras.ru [83.149.199.91]) by sourceware.org (Postfix) with ESMTP id A6426389F4F9 for ; Tue, 10 Mar 2020 12:20:47 +0000 (GMT) Received: from [10.10.3.54] (utre4ko.intra.ispras.ru [10.10.3.54]) by smtp.ispras.ru (Postfix) with ESMTP id C7373203BF; Tue, 10 Mar 2020 15:20:44 +0300 (MSK) Subject: Re: [PATCH] issues with configure --enable-checking option From: Roman Zhuykov To: Jakub Jelinek , "gcc-patches@gcc.gnu.org" Cc: Sandra Loosemore , 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> Message-ID: <631009bf-ff65-29b8-837a-8df597ecf097@ispras.ru> Date: Tue, 10 Mar 2020 15:20:44 +0300 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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-19.4 required=5.0 tests=BAYES_00, GARBLED_BODY, GIT_PATCH_0, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 12:20:51 -0000 Hi! 25.02.2020 13:36, Roman Zhuykov wrote: > So, IMHO the best next step is to improve the behavior rather then docs :) I want to add one more point into this discussion.  I have recently decided to test some stuff on old branches, e.q gcc-4.9, 5 and 6. On modern systems there are some issues with building old branches, at least I met "struct ucontext -> ucontext_t", "sys/ustat.h - no such file" and few others.  But in this particular experiment, I was using pretty old Ubuntu 16.04, and there were no issues with building unpatched frozen branches. But, since the stuff was really experimental, at some moment I've decided to apply the following to enable more checking: diff --git a/gcc/DEV-PHASE b/gcc/DEV-PHASE --- a/gcc/DEV-PHASE +++ b/gcc/DEV-PHASE @@ -0,0 +1 @@ +experimental diff --git a/gcc/configure b/gcc/configure --- a/gcc/configure +++ b/gcc/configure @@ -6727,7 +6727,7 @@ do      # these set all the flags to specific states      yes)        ac_assert_checking=1 ; ac_checking=1 ; ac_df_checking= ;              ac_fold_checking= ; ac_gc_checking=1 ; -            ac_gc_always_collect= ; ac_gimple_checking=1 ; ac_rtl_checking= ; +            ac_gc_always_collect= ; ac_gimple_checking=1 ; ac_rtl_checking=1 ;              ac_rtlflag_checking=1 ; ac_runtime_checking=1 ;              ac_tree_checking=1 ; ac_valgrind_checking= ;              ac_types_checking=1 ;; diff --git a/gcc/configure.ac b/gcc/configure.ac --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -427,7 +427,7 @@ do      # these set all the flags to specific states      yes)        ac_assert_checking=1 ; ac_checking=1 ; ac_df_checking= ;              ac_fold_checking= ; ac_gc_checking=1 ; -            ac_gc_always_collect= ; ac_gimple_checking=1 ; ac_rtl_checking= ; +            ac_gc_always_collect= ; ac_gimple_checking=1 ; ac_rtl_checking=1 ;              ac_rtlflag_checking=1 ; ac_runtime_checking=1 ;              ac_tree_checking=1 ; ac_valgrind_checking= ;              ac_types_checking=1 ;; And that gives broken basic x86_64 bootstrap on gcc-5 and gcc-6 branches! First, about gcc-4.9 branch, it works fine.  There was another story that it failed with rtl checks on ppc64.  Alex told me there was some moment when all folks forgot to test that.  So, everything went fine after backporting r243144 (r5-10072) and r212829 (r5-1977). But the gcc-5 branch case was much more tricky.  The following 3 hunks are needed to fix x86_64 bootstrap. And that one with UNKNOWN_LOCATION is really a null pointer dereference we put into a released compiler! diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c --- a/gcc/fortran/frontend-passes.c +++ b/gcc/fortran/frontend-passes.c @@ -138,7 +138,7 @@ gfc_run_passes (gfc_namespace *ns)   */    static int -realloc_string_callback (gfc_code **c, int *walk_subtrees, +realloc_string_callback (gfc_code **c, int *walk_subtrees ATTRIBUTE_UNUSED,               void *data ATTRIBUTE_UNUSED)  {    gfc_expr *expr1, *expr2; diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c --- a/gcc/fortran/trans-openmp.c +++ b/gcc/fortran/trans-openmp.c @@ -38,7 +38,6 @@ along with GCC; see the file COPYING3.  If not see  #include "gimplify.h"    /* For create_tmp_var_raw.  */  #include "stringpool.h"  #include "gfortran.h" -#include "diagnostic-core.h"    /* For internal_error.  */  #include "trans.h"  #include "trans-stmt.h"  #include "trans-types.h" diff --git a/gcc/toplev.c b/gcc/toplev.c --- a/gcc/toplev.c +++ b/gcc/toplev.c @@ -1386,8 +1386,7 @@ process_options (void)          if (flag_sanitize & SANITIZE_THREAD)      { -      error (UNKNOWN_LOCATION, -         "%<-fcheck-pointer-bounds%> is not supported with " +      error ("%<-fcheck-pointer-bounds%> is not supported with "           "Thread Sanitizer");          flag_check_pointer_bounds = 0; In gcc-6 branch the solution was simple - I have to revert r262046 (r6-10168), haven't investigate that deeply. Overall, IMHO this is one more point to review current branching/checking approach. So, I understand that main purpose of empty DEV-PHASE is to test "almost released" compiler in the same way it will be compiled from release archives. But those issues show it's also necessary to run checking-bootstrap when backporting any patch. PS. Everything seems fine in gcc-7 branch. Roman