Re: Add new macro gl_WARN_ADD_MULTIPLE
Hi Bruno, On 02.05.19 21:12, Bruno Haible wrote: >>> Does this implementation of manywarnings support only the case where >>> you want all possible warnings except an explicitly specified set? >>> Or also the case where you want only an explicitly specified set of >>> warnings? >> >> It supports the first approach only, in detail >> - all warnings except a given subset >> - you can add warnings, e.g. you might need -Wno-... for warnings that >> are implicitly enabled. Especially with clang where '--help=warnings -Q' >> isn't available. Here we use -Weverything and you have to add options to >> silence some of the overly expressive warnings. > > OK, but a similar thing can be done for the opposite case (just with no > -Weverything). So we could have two macros > gl_MANYWARN_GCC_ALL_EXCEPT([warnings to disable]) This is already there, you fill $WARN_CFLAGS with all C warn flags with wget_MANYWARNINGS(WARN_CFLAGS, C) Now you can remove your unwanted warn flags via wget_WORD_REMOVE([WARN_CFLAGS], [$WARN_CFLAGS], [list of unwanted warnings]) > gl_MANYWARN_GCC_ENABLE([warnings to enable]) see below... > >> It works only with gcc 4.3+. > > We can keep the existing, slower code around and use it for GCC versions > < 4.2. > >>> Or also the case where you want only an explicitly specified set of >>> warnings? >> >> If you need that, why not just set CFLAGS ? Or maybe I don't understand >> exactly... > > Because GCC freaks out when you pass it warning options that it does not > understand. The whole point of this testing is to pass to GCC only those > options that will not make it freak out. I understand, but have a use case for this. It means I have to keep this list up-to-date with each new compiler version (checking what is new and if i want to add it to the list). That is maintenance burden I try to avoid with my approach, were I automatically make use of new warning flags. E.g. after the next 'apt upgrade' I might pull in gcc 9 and the next build just might come up with new warnings... Regards, Tim signature.asc Description: OpenPGP digital signature
Re: Add new macro gl_WARN_ADD_MULTIPLE
Hi Tim, > > Does this implementation of manywarnings support only the case where > > you want all possible warnings except an explicitly specified set? > > Or also the case where you want only an explicitly specified set of > > warnings? > > It supports the first approach only, in detail > - all warnings except a given subset > - you can add warnings, e.g. you might need -Wno-... for warnings that > are implicitly enabled. Especially with clang where '--help=warnings -Q' > isn't available. Here we use -Weverything and you have to add options to > silence some of the overly expressive warnings. OK, but a similar thing can be done for the opposite case (just with no -Weverything). So we could have two macros gl_MANYWARN_GCC_ALL_EXCEPT([warnings to disable]) gl_MANYWARN_GCC_ENABLE([warnings to enable]) > It works only with gcc 4.3+. We can keep the existing, slower code around and use it for GCC versions < 4.2. > > Or also the case where you want only an explicitly specified set of > > warnings? > > If you need that, why not just set CFLAGS ? Or maybe I don't understand > exactly... Because GCC freaks out when you pass it warning options that it does not understand. The whole point of this testing is to pass to GCC only those options that will not make it freak out. Bruno
Re: Add new macro gl_WARN_ADD_MULTIPLE
Hi Bruno, On 02.05.19 13:28, Bruno Haible wrote: > Hi Tim, > >> Mentioned 2 years ago (but being still too busy to make a gnulib module >> from it); Wget2's implementation using --help=warnings is here and FSF >> copyrighted: >> >> https://gitlab.com/gnuwget/wget2/blob/master/m4/wget_manywarnings.m4 >> >> And how to use / fine-tune it can be seen in L106 of >> >> https://gitlab.com/gnuwget/wget2/blob/master/configure.ac > > Does this implementation of manywarnings support only the case where > you want all possible warnings except an explicitly specified set? > Or also the case where you want only an explicitly specified set of > warnings? It supports the first approach only, in detail - all warnings except a given subset - you can add warnings, e.g. you might need -Wno-... for warnings that are implicitly enabled. Especially with clang where '--help=warnings -Q' isn't available. Here we use -Weverything and you have to add options to silence some of the overly expressive warnings. This approach benefits from new options in newer versions of gcc/clang without maintaining lists of options in the .m4 file. The original idea was to avoid compiler calls to reduce configure time. It works only with gcc 4.3+. > Or also the case where you want only an explicitly specified set of > warnings? If you need that, why not just set CFLAGS ? Or maybe I don't understand exactly... > Although I think that the first approach is the better one in the long > run, some projects may want to use the second approach, and the gnulib > module so far supports both approaches. > >> There is gcc and clang support. > > This way of detecting clang is not portable: > > case $CC in > *gcc*) CCNAME="gcc";; > *clang*) CCNAME="clang";; > esac > > On FreeBSD, for example, $CC = "cc" is clang but you cannot know it > by looking at the command name. You need to run the preprocessor and > see how it processes > #if defined __clang__ Thanks, good to know. Our development env is a pretty up-to-date GNU/Linux with a recent gcc and clang - that is were we use --enable-manywarnings. Of course this macro file has to be fine-tuned for other development environments. So anyone wanting to use the feature on FreeBSD, Windows+MSVC or wherever is free to contribute. (But I don't expect much from that direction.) Regards, Tim signature.asc Description: OpenPGP digital signature
Re: Add new macro gl_WARN_ADD_MULTIPLE
Hi Tim, > Mentioned 2 years ago (but being still too busy to make a gnulib module > from it); Wget2's implementation using --help=warnings is here and FSF > copyrighted: > > https://gitlab.com/gnuwget/wget2/blob/master/m4/wget_manywarnings.m4 > > And how to use / fine-tune it can be seen in L106 of > > https://gitlab.com/gnuwget/wget2/blob/master/configure.ac Does this implementation of manywarnings support only the case where you want all possible warnings except an explicitly specified set? Or also the case where you want only an explicitly specified set of warnings? Although I think that the first approach is the better one in the long run, some projects may want to use the second approach, and the gnulib module so far supports both approaches. > There is gcc and clang support. This way of detecting clang is not portable: case $CC in *gcc*) CCNAME="gcc";; *clang*) CCNAME="clang";; esac On FreeBSD, for example, $CC = "cc" is clang but you cannot know it by looking at the command name. You need to run the preprocessor and see how it processes #if defined __clang__ Bruno
Re: Add new macro gl_WARN_ADD_MULTIPLE
On 5/2/19 10:16 AM, Bruno Haible wrote: > Hi Alex, > >> GNU Emacs spends about ~6s out of ~28s in its configuration process to >> determine supported C compiler warnings. > > It's good that you tackle this problem. Thanks! > >> This macro first checks if all the supplied warnings are >> supported, and then only checks them individually (via gl_WARN_ADD) if >> that check fails. > > So, the speed improvement exists only for the newest compilers; people > who use a compiler that was released 1 or 2 years before the Emacs release > will see no improvement. > > How about a modified algorithm? > 1) In a first pass, use the GCC's --help=warnings output to determine which > warnings are likely supported. Unfortunately, for clang, I don't know > of such a help option. > 2) When the first check (with all the options) fails, split that list into > 2 (or 3, or 4) chunks of nearly equal size, and perform the check > on each sub-list. And so on, recurse. > This way, you would still get some performance benefit if the compiler > supports 80% of the requested warnings but not all of them. > > Finally, since there is no semantic difference between gl_WARN_ADD and > gl_WARN_ADD_MULTIPLE, except that the latter allows multiple options, how > about extending the gl_WARN_ADD macro (to allow multiple options) instead > of defining a different macro (gl_WARN_ADD_MULTIPLE)? Mentioned 2 years ago (but being still too busy to make a gnulib module from it); Wget2's implementation using --help=warnings is here and FSF copyrighted: https://gitlab.com/gnuwget/wget2/blob/master/m4/wget_manywarnings.m4 And how to use / fine-tune it can be seen in L106 of https://gitlab.com/gnuwget/wget2/blob/master/configure.ac There is gcc and clang support. The configure.ac creates two sets of compiler flags, for wget2/libwget sources and for gnulib sources. Regards, Tim signature.asc Description: OpenPGP digital signature
Re: Add new macro gl_WARN_ADD_MULTIPLE
Hi Alex, > GNU Emacs spends about ~6s out of ~28s in its configuration process to > determine supported C compiler warnings. It's good that you tackle this problem. Thanks! > This macro first checks if all the supplied warnings are > supported, and then only checks them individually (via gl_WARN_ADD) if > that check fails. So, the speed improvement exists only for the newest compilers; people who use a compiler that was released 1 or 2 years before the Emacs release will see no improvement. How about a modified algorithm? 1) In a first pass, use the GCC's --help=warnings output to determine which warnings are likely supported. Unfortunately, for clang, I don't know of such a help option. 2) When the first check (with all the options) fails, split that list into 2 (or 3, or 4) chunks of nearly equal size, and perform the check on each sub-list. And so on, recurse. This way, you would still get some performance benefit if the compiler supports 80% of the requested warnings but not all of them. Finally, since there is no semantic difference between gl_WARN_ADD and gl_WARN_ADD_MULTIPLE, except that the latter allows multiple options, how about extending the gl_WARN_ADD macro (to allow multiple options) instead of defining a different macro (gl_WARN_ADD_MULTIPLE)? Bruno
Add new macro gl_WARN_ADD_MULTIPLE
GNU Emacs spends about ~6s out of ~28s in its configuration process to determine supported C compiler warnings. The attached patch introduces a new macro, gl_WARN_ADD_MULTIPLE, that brings this down to about half a second. This macro first checks if all the supplied warnings are supported, and then only checks them individually (via gl_WARN_ADD) if that check fails. I have also attached sample files configure-prev.ac and configure-new.ac that were extracted from Emacs's configure.ac for testing. I created a new directory, copied m4/warnings.m4 and m4/manywarnings.m4 to a new m4 subdirectory, and ran: autoconf -f then benchmarked using: perf stat -r 20 ./configure Results of configure-prev.ac: Performance counter stats for './configure' (20 runs): 6,285.79 msec task-clock:u 0 context-switches:u 0 cpu-migrations:u 918,039 page-faults:u 11,101,658,357 cycles:u 12,777,542,067 stalled-cycles-frontend:u 11,234,412,307 stalled-cycles-backend:u 14,261,222,341 instructions:u 2,906,440,712 branches:u 100,574,333 branch-misses:u 6.34363 +- 0.00614 seconds time elapsed ( +- 0.10% ) Results of configure-new.ac: Performance counter stats for './configure' (20 runs): 530.29 msec task-clock:u 0 context-switches:u 0 cpu-migrations:u 72,010 page-faults:u 901,496,456 cycles:u 1,066,313,480 stalled-cycles-frontend:u 949,724,068 stalled-cycles-backend:u 1,240,144,586 instructions:u 254,307,360 branches:u 7,217,416 branch-misses:u 0.53320 +- 0.00210 seconds time elapsed ( +- 0.39% ) Results of configure-new.ac with a forced fallback (I added a nonexistent warning to ws): Performance counter stats for './configure' (20 runs): 5,992.42 msec task-clock:u 0 context-switches:u 0 cpu-migrations:u 935,599 page-faults:u 11,197,607,809 cycles:u 12,982,878,617 stalled-cycles-frontend:u 11,427,814,210 stalled-cycles-backend:u 14,333,736,238 instructions:u 2,918,880,583 branches:u 100,570,882 branch-misses:u 6.0497 +- 0.0468 seconds time elapsed ( +- 0.77% ) >From ec89f6d04a6b5ac67ec787d28943e4fa4188e5f4 Mon Sep 17 00:00:00 2001 From: Alexander Gramiak Date: Wed, 1 May 2019 16:31:23 -0600 Subject: [PATCH] warnings: Add new macro gl_WARN_ADD_MULTIPLE * m4/warnings.m4 (gl_WARN_ADD_MULTIPLE): New macro. --- ChangeLog | 5 + m4/warnings.m4 | 46 ++ 2 files changed, 51 insertions(+) diff --git a/ChangeLog b/ChangeLog index cf4116bf3..324112055 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2019-05-01 Alexander Gramiak + + warnings: Add new macro gl_WARN_ADD_MULTIPLE + * m4/warnings.m4 (gl_WARN_ADD_MULTIPLE): New macro. + 2019-04-30 Paul Eggert Sync lib/mktime-internal.h from glibc diff --git a/m4/warnings.m4 b/m4/warnings.m4 index 235cac617..92939233d 100644 --- a/m4/warnings.m4 +++ b/m4/warnings.m4 @@ -49,6 +49,52 @@ AS_VAR_POPDEF([gl_Flags])dnl AS_VAR_POPDEF([gl_Warn])dnl ]) +# gl_WARN_ADD_MULTIPLE(OPTIONS, [VARIABLE = WARN_CFLAGS/WARN_CXXFLAGS], +# [PROGRAM = AC_LANG_PROGRAM()]) +# - +# Check if the compiler supports OPTIONS when compiling PROGRAM +# First check if all OPTIONS are supported together, and if not, +# check each option individually. +# +# The effects of this macro depend on the current language (_AC_LANG). +AC_DEFUN([gl_WARN_ADD_MULTIPLE], +[ +dnl FIXME: gl_Warn must be used unquoted until we can assume Autoconf +dnl 2.64 or newer. +AS_VAR_PUSHDEF([gl_Warn], [gl_cv_warn_[]_AC_LANG_ABBREV[]_$1])dnl +AS_VAR_PUSHDEF([gl_Flags], [_AC_LANG_PREFIX[]FLAGS])dnl +gl_positives= +for gl_warn_item in $1; do + case $gl_warn_item in +-Wno-*) gl_positives="$gl_positives -W`expr "X$gl_warn_item" : 'X-Wno-\(.*\)'`" ;; +*) gl_positives="$gl_positives $gl_warn_item" + esac +done +m4_pushdef([gl_Positives], [$gl_positives])dnl +AC_CACHE_CHECK([whether _AC_LANG compiler handles $1], m4_defn([gl_Warn]), [ + gl_save_compiler_FLAGS="$gl_Flags" + gl_AS_VAR_AP
