diff mbox

[1/9] ENABLE_CHECKING refactoring

Message ID CAFiYyc1T2CncaryaONw+30-y2t3uppStMx6q1p+6WDWB6nxqHw@mail.gmail.com
State New
Headers show

Commit Message

Richard Biener Oct. 6, 2015, 12:53 p.m. UTC 
On Tue, Oct 6, 2015 at 1:27 AM, Mikhail Maltsev <maltsevm@gmail.com> wrote:
> Hi!
>
> This is an updated series of patches which converts 'ENABLE_CHECKING' macro into
> a flag, 'flag_checking' (and 'CHECKING_P' macro in several cases). For now
> flag_checking is always initialized with the value of 'CHECKING_P', but later it
> can be turned into a proper command-line flag and probably split into several
> checks. I also added several function which verify internal data structures when
> flag_checking is enabled (e.g. checking_verify_flow_info which calls
> verify_flow_info). These functions make their callers look somewhat cleaner.
>
> The cases where I left 'CHECKING_P' are:
> 1. libcpp (turn ICE after an error into fatal error) and pretty-printers (that
> would require to pass flag_checking to libcpp just for this single case).
> 2. Code which fills memory in the pools with some predefined patterns in
> deallocation methods (this would add some overhead to each deallocation), though
> I have not measured performance impact yet.
> 3. Generators and generated code.
> 4. Target-specific code
> 5. 'struct lra_reg' which has an additional field in checking build
> 6. Likewise, 'struct moveop_static_params' in insn scheduler and
> 'cumulative_args_t' in target.h.
> 7. macro-related code in libcpp (for the same reason)
> 8. real.c and fwprop.c - I'll profile these and also fix to use flag_checking if
> there won't be any measurable overhead.
>
> There are 9 patches:
> 1. Add flag_checking and CHECKING_P macros
> 2. Use CHECKING_P in libcpp
> 3. Ada and Java frontends
> 4. Fortran frontend
> 5. Pool allocators
> 6. Generator programs
> 7. Most of middle-end (GIMPLE, IPA, RTL) - it can be split further, if needed.
> 8. Target-specific code
> 9. C++ frontend - in progress (I will send this part soon).
>
> Some issues related to checking builds:
> 1. Useless check in graphite: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67842
> 2. I found a test which fails only on release builds:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583 (reopened)
> 3. Another one: gcc.c-torture/compile/pr52073.c which is, I guess, caused by
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67816 (the backtrace is the same,
> at least).
>
> Each patch (when applied on top of all the previous ones) compiles in both
> checking and release builds. The combined patch passes bootstrap and regression
> tests in checking an release builds (apart from 2 issues mentioned above) on
> x86_64-linux. I'll also run it through config-list.mk.

This looks ok to me, though I'd have defined CHECKING_P from configure.ac where
we define ENABLE_CHECKING.


should do that?

Richard.


> --
> Regards,
>     Mikhail Maltsev
>
>
> gcc/ChangeLog:
>
> 2015-10-05  Mikhail Maltsev  <maltsevm@gmail.com>
>
>         * common.opt: Add flag_checking.
>         * system.h (CHECKING_P): Define.
>
> libcpp/ChangeLog:
>
> 2015-10-05  Mikhail Maltsev  <maltsevm@gmail.com>
>
>         * system.h (CHECKING_P, gcc_checking_assert): Define.
diff mbox

Patch

Index: gcc/configure.ac
===================================================================
--- gcc/configure.ac    (revision 228519)
+++ gcc/configure.ac    (working copy)
@@ -569,7 +569,10 @@  if test x$ac_checking != x ; then
   AC_DEFINE(ENABLE_CHECKING, 1,
 [Define if you want more run-time sanity checks.  This one gets a grab
    bag of miscellaneous but relatively cheap checks.])
+  AC_DEFINE(CHECKING_P, 1)
   nocommon_flag=-fno-common
+else
+  AC_DEFINE(CHECKING_P, 0)
 fi
 AC_SUBST(nocommon_flag)
 if test x$ac_df_checking != x ; then