On Tue, Oct 6, 2015 at 1:27 AM, Mikhail Maltsev <malts...@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.
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
should do that?
Richard.
> --
> Regards,
> Mikhail Maltsev
>
>
> gcc/ChangeLog:
>
> 2015-10-05 Mikhail Maltsev <malts...@gmail.com>
>
> * common.opt: Add flag_checking.
> * system.h (CHECKING_P): Define.
>
> libcpp/ChangeLog:
>
> 2015-10-05 Mikhail Maltsev <malts...@gmail.com>
>
> * system.h (CHECKING_P, gcc_checking_assert): Define.
