* [PATCH] gdbsupport: better detection of -Wmissing-prototypes support @ 2021-09-24 12:29 Andrew Burgess 2021-09-24 13:16 ` Andrew Burgess 2021-09-24 15:14 ` [PATCHv2] " Andrew Burgess 0 siblings, 2 replies; 10+ messages in thread From: Andrew Burgess @ 2021-09-24 12:29 UTC (permalink / raw) To: gdb-patches When building with GCC 9.3.1 I notice lots of warnings like this while building GDB: cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ This is a little strange as the configure macro, AM_GDB_WARNINGS, should figure out which warning flags are valid, and which are not. It turns out that there's a weird bug in some older version of GCC; when performing only a compile, the -Wmissing-prototypes flag will only ever produce a warning, even when -Werror is passed. If a full compile and link is performed then an error is produced (assuming -Werror is passed). Of course, the AM_GDB_WARNINGS macro only tests each flag during a compile, not a compile and link, so the macro figures that the -Wmissing-prototypes flag is valid (even though a warning is emitted), and adds it to the set of flags to use. In this commit I special case the -Wmissing-prototypes check inside AM_GDB_WARNINGS, and for that flag only, we now perform a full compile and link. This means that the configure script can correctly detect that the flag is not supported, and so the flag is no longer used. --- gdb/configure | 25 +++++++++++++++++++++++++ gdbserver/configure | 25 +++++++++++++++++++++++++ gdbsupport/configure | 25 +++++++++++++++++++++++++ gdbsupport/warning.m4 | 14 ++++++++++++++ 4 files changed, 89 insertions(+) diff --git a/gdb/configure b/gdb/configure index f0b1af4a6ea..1bd9a7698b7 100755 --- a/gdb/configure +++ b/gdb/configure @@ -17016,6 +17016,31 @@ if ac_fn_cxx_try_compile "$LINENO"; then : WARN_CFLAGS="${WARN_CFLAGS} $w" fi rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext + elif test "x$w" = "x-Wmissing-prototypes"; then + # On some versions of GCC, e.g. 9.3.1, even when -Werror + # is passed, the -Wmissing-prototypes flag will only + # ever produce a warning when compiling, but, will + # produce an error when a full link is performed. This + # bug is fixed in later versions of GCC. + # + # To avoid this bug, and detect if -Wmissing-prototypes + # is supported, we do a compile and link here. + cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ + +int +main () +{ + + ; + return 0; +} +_ACEOF +if ac_fn_cxx_try_link "$LINENO"; then : + WARN_CFLAGS="${WARN_CFLAGS} $w" +fi +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext else cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ diff --git a/gdbserver/configure b/gdbserver/configure index b227167e270..c12354f583c 100755 --- a/gdbserver/configure +++ b/gdbserver/configure @@ -9766,6 +9766,31 @@ if ac_fn_cxx_try_compile "$LINENO"; then : WARN_CFLAGS="${WARN_CFLAGS} $w" fi rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext + elif test "x$w" = "x-Wmissing-prototypes"; then + # On some versions of GCC, e.g. 9.3.1, even when -Werror + # is passed, the -Wmissing-prototypes flag will only + # ever produce a warning when compiling, but, will + # produce an error when a full link is performed. This + # bug is fixed in later versions of GCC. + # + # To avoid this bug, and detect if -Wmissing-prototypes + # is supported, we do a compile and link here. + cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ + +int +main () +{ + + ; + return 0; +} +_ACEOF +if ac_fn_cxx_try_link "$LINENO"; then : + WARN_CFLAGS="${WARN_CFLAGS} $w" +fi +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext else cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ diff --git a/gdbsupport/configure b/gdbsupport/configure index a9dd02c5b72..ff8eb517d9e 100755 --- a/gdbsupport/configure +++ b/gdbsupport/configure @@ -10251,6 +10251,31 @@ if ac_fn_cxx_try_compile "$LINENO"; then : WARN_CFLAGS="${WARN_CFLAGS} $w" fi rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext + elif test "x$w" = "x-Wmissing-prototypes"; then + # On some versions of GCC, e.g. 9.3.1, even when -Werror + # is passed, the -Wmissing-prototypes flag will only + # ever produce a warning when compiling, but, will + # produce an error when a full link is performed. This + # bug is fixed in later versions of GCC. + # + # To avoid this bug, and detect if -Wmissing-prototypes + # is supported, we do a compile and link here. + cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ + +int +main () +{ + + ; + return 0; +} +_ACEOF +if ac_fn_cxx_try_link "$LINENO"; then : + WARN_CFLAGS="${WARN_CFLAGS} $w" +fi +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext else cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ diff --git a/gdbsupport/warning.m4 b/gdbsupport/warning.m4 index 46036fa461e..7bb8176b50f 100644 --- a/gdbsupport/warning.m4 +++ b/gdbsupport/warning.m4 @@ -150,6 +150,20 @@ then [WARN_CFLAGS="${WARN_CFLAGS} $w"], [] ) + elif test "x$w" = "x-Wmissing-prototypes"; then + # On some versions of GCC, e.g. 9.3.1, even when -Werror + # is passed, the -Wmissing-prototypes flag will only + # ever produce a warning when compiling, but, will + # produce an error when a full link is performed. This + # bug is fixed in later versions of GCC. + # + # To avoid this bug, and detect if -Wmissing-prototypes + # is supported, we do a compile and link here. + AC_LINK_IFELSE( + [AC_LANG_PROGRAM([],[])], + [WARN_CFLAGS="${WARN_CFLAGS} $w"], + [] + ) else AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([], [])], -- 2.25.4 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support 2021-09-24 12:29 [PATCH] gdbsupport: better detection of -Wmissing-prototypes support Andrew Burgess @ 2021-09-24 13:16 ` Andrew Burgess 2021-09-24 13:40 ` Simon Marchi via Gdb-patches 2021-09-24 15:14 ` [PATCHv2] " Andrew Burgess 1 sibling, 1 reply; 10+ messages in thread From: Andrew Burgess @ 2021-09-24 13:16 UTC (permalink / raw) To: gdb-patches * Andrew Burgess <andrew.burgess@embecosm.com> [2021-09-24 13:29:33 +0100]: > When building with GCC 9.3.1 I notice lots of warnings like this while > building GDB: > > cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ > > This is a little strange as the configure macro, AM_GDB_WARNINGS, > should figure out which warning flags are valid, and which are not. > > It turns out that there's a weird bug in some older version of GCC; > when performing only a compile, the -Wmissing-prototypes flag will > only ever produce a warning, even when -Werror is passed. If a full > compile and link is performed then an error is produced (assuming > -Werror is passed). > > Of course, the AM_GDB_WARNINGS macro only tests each flag during a > compile, not a compile and link, so the macro figures that the > -Wmissing-prototypes flag is valid (even though a warning is emitted), > and adds it to the set of flags to use. > > In this commit I special case the -Wmissing-prototypes check inside > AM_GDB_WARNINGS, and for that flag only, we now perform a full compile > and link. This means that the configure script can correctly detect > that the flag is not supported, and so the flag is no longer used. It has been pointed out to me on IRC (thanks Simon), that this issue is not GCC, but ccache: https://github.com/ccache/ccache/issues/738#issuecomment-740133374 So this patch certainly shouldn't go in as it is currently written. It's still pretty annoying seeing those warnings though, so I wonder if we can consider having a work around for this ccache issue in the GDB configure scripts? Maybe something as simple as setting CCACHE_DISABLE in the environment prior to running the AM_GDB_WARNINGS checks? All ideas welcome... thanks, Andrewx > --- > gdb/configure | 25 +++++++++++++++++++++++++ > gdbserver/configure | 25 +++++++++++++++++++++++++ > gdbsupport/configure | 25 +++++++++++++++++++++++++ > gdbsupport/warning.m4 | 14 ++++++++++++++ > 4 files changed, 89 insertions(+) > > diff --git a/gdb/configure b/gdb/configure > index f0b1af4a6ea..1bd9a7698b7 100755 > --- a/gdb/configure > +++ b/gdb/configure > @@ -17016,6 +17016,31 @@ if ac_fn_cxx_try_compile "$LINENO"; then : > WARN_CFLAGS="${WARN_CFLAGS} $w" > fi > rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext > + elif test "x$w" = "x-Wmissing-prototypes"; then > + # On some versions of GCC, e.g. 9.3.1, even when -Werror > + # is passed, the -Wmissing-prototypes flag will only > + # ever produce a warning when compiling, but, will > + # produce an error when a full link is performed. This > + # bug is fixed in later versions of GCC. > + # > + # To avoid this bug, and detect if -Wmissing-prototypes > + # is supported, we do a compile and link here. > + cat confdefs.h - <<_ACEOF >conftest.$ac_ext > +/* end confdefs.h. */ > + > +int > +main () > +{ > + > + ; > + return 0; > +} > +_ACEOF > +if ac_fn_cxx_try_link "$LINENO"; then : > + WARN_CFLAGS="${WARN_CFLAGS} $w" > +fi > +rm -f core conftest.err conftest.$ac_objext \ > + conftest$ac_exeext conftest.$ac_ext > else > cat confdefs.h - <<_ACEOF >conftest.$ac_ext > /* end confdefs.h. */ > diff --git a/gdbserver/configure b/gdbserver/configure > index b227167e270..c12354f583c 100755 > --- a/gdbserver/configure > +++ b/gdbserver/configure > @@ -9766,6 +9766,31 @@ if ac_fn_cxx_try_compile "$LINENO"; then : > WARN_CFLAGS="${WARN_CFLAGS} $w" > fi > rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext > + elif test "x$w" = "x-Wmissing-prototypes"; then > + # On some versions of GCC, e.g. 9.3.1, even when -Werror > + # is passed, the -Wmissing-prototypes flag will only > + # ever produce a warning when compiling, but, will > + # produce an error when a full link is performed. This > + # bug is fixed in later versions of GCC. > + # > + # To avoid this bug, and detect if -Wmissing-prototypes > + # is supported, we do a compile and link here. > + cat confdefs.h - <<_ACEOF >conftest.$ac_ext > +/* end confdefs.h. */ > + > +int > +main () > +{ > + > + ; > + return 0; > +} > +_ACEOF > +if ac_fn_cxx_try_link "$LINENO"; then : > + WARN_CFLAGS="${WARN_CFLAGS} $w" > +fi > +rm -f core conftest.err conftest.$ac_objext \ > + conftest$ac_exeext conftest.$ac_ext > else > cat confdefs.h - <<_ACEOF >conftest.$ac_ext > /* end confdefs.h. */ > diff --git a/gdbsupport/configure b/gdbsupport/configure > index a9dd02c5b72..ff8eb517d9e 100755 > --- a/gdbsupport/configure > +++ b/gdbsupport/configure > @@ -10251,6 +10251,31 @@ if ac_fn_cxx_try_compile "$LINENO"; then : > WARN_CFLAGS="${WARN_CFLAGS} $w" > fi > rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext > + elif test "x$w" = "x-Wmissing-prototypes"; then > + # On some versions of GCC, e.g. 9.3.1, even when -Werror > + # is passed, the -Wmissing-prototypes flag will only > + # ever produce a warning when compiling, but, will > + # produce an error when a full link is performed. This > + # bug is fixed in later versions of GCC. > + # > + # To avoid this bug, and detect if -Wmissing-prototypes > + # is supported, we do a compile and link here. > + cat confdefs.h - <<_ACEOF >conftest.$ac_ext > +/* end confdefs.h. */ > + > +int > +main () > +{ > + > + ; > + return 0; > +} > +_ACEOF > +if ac_fn_cxx_try_link "$LINENO"; then : > + WARN_CFLAGS="${WARN_CFLAGS} $w" > +fi > +rm -f core conftest.err conftest.$ac_objext \ > + conftest$ac_exeext conftest.$ac_ext > else > cat confdefs.h - <<_ACEOF >conftest.$ac_ext > /* end confdefs.h. */ > diff --git a/gdbsupport/warning.m4 b/gdbsupport/warning.m4 > index 46036fa461e..7bb8176b50f 100644 > --- a/gdbsupport/warning.m4 > +++ b/gdbsupport/warning.m4 > @@ -150,6 +150,20 @@ then > [WARN_CFLAGS="${WARN_CFLAGS} $w"], > [] > ) > + elif test "x$w" = "x-Wmissing-prototypes"; then > + # On some versions of GCC, e.g. 9.3.1, even when -Werror > + # is passed, the -Wmissing-prototypes flag will only > + # ever produce a warning when compiling, but, will > + # produce an error when a full link is performed. This > + # bug is fixed in later versions of GCC. > + # > + # To avoid this bug, and detect if -Wmissing-prototypes > + # is supported, we do a compile and link here. > + AC_LINK_IFELSE( > + [AC_LANG_PROGRAM([],[])], > + [WARN_CFLAGS="${WARN_CFLAGS} $w"], > + [] > + ) > else > AC_COMPILE_IFELSE( > [AC_LANG_PROGRAM([], [])], > -- > 2.25.4 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support 2021-09-24 13:16 ` Andrew Burgess @ 2021-09-24 13:40 ` Simon Marchi via Gdb-patches 2021-09-24 14:06 ` Pedro Alves 0 siblings, 1 reply; 10+ messages in thread From: Simon Marchi via Gdb-patches @ 2021-09-24 13:40 UTC (permalink / raw) To: Andrew Burgess, gdb-patches On 2021-09-24 9:16 a.m., Andrew Burgess wrote: > It has been pointed out to me on IRC (thanks Simon), that this issue > is not GCC, but ccache: > > https://github.com/ccache/ccache/issues/738#issuecomment-740133374 > > So this patch certainly shouldn't go in as it is currently written. > > It's still pretty annoying seeing those warnings though, so I wonder > if we can consider having a work around for this ccache issue in the > GDB configure scripts? > > Maybe something as simple as setting CCACHE_DISABLE in the environment > prior to running the AM_GDB_WARNINGS checks? > > All ideas welcome... Either way would be fine with me: - to use AC_LINK_IFELSE all the time (I don't think the execution time would be significantly higher) - to set CCACHE_DISABLE during the execution of AM_GDB_WARNINGS Simon ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support 2021-09-24 13:40 ` Simon Marchi via Gdb-patches @ 2021-09-24 14:06 ` Pedro Alves 2021-09-24 14:22 ` Simon Marchi via Gdb-patches 0 siblings, 1 reply; 10+ messages in thread From: Pedro Alves @ 2021-09-24 14:06 UTC (permalink / raw) To: Simon Marchi, Andrew Burgess, gdb-patches On 2021-09-24 2:40 p.m., Simon Marchi via Gdb-patches wrote: > On 2021-09-24 9:16 a.m., Andrew Burgess wrote: >> It has been pointed out to me on IRC (thanks Simon), that this issue >> is not GCC, but ccache: >> >> https://github.com/ccache/ccache/issues/738#issuecomment-740133374 >> >> So this patch certainly shouldn't go in as it is currently written. >> >> It's still pretty annoying seeing those warnings though, so I wonder >> if we can consider having a work around for this ccache issue in the >> GDB configure scripts? >> >> Maybe something as simple as setting CCACHE_DISABLE in the environment >> prior to running the AM_GDB_WARNINGS checks? >> >> All ideas welcome... > > Either way would be fine with me: > > - to use AC_LINK_IFELSE all the time (I don't think the execution time > would be significantly higher) > - to set CCACHE_DISABLE during the execution of AM_GDB_WARNINGS Does working around this in configure tests still mean that when using ccache for really building gdb, ccache will still misreorder arguments and thus potentially a -Wmissing-prototypes warning would not be turned into an error? So, here's another option, I think: #3 - drop -Wmissing-prototypes completely. As the GCC warning says, cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ it's only valid for C, not C++. Do we compile anything with a C compiler nowadays? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support 2021-09-24 14:06 ` Pedro Alves @ 2021-09-24 14:22 ` Simon Marchi via Gdb-patches 2021-09-24 14:30 ` Pedro Alves 0 siblings, 1 reply; 10+ messages in thread From: Simon Marchi via Gdb-patches @ 2021-09-24 14:22 UTC (permalink / raw) To: Pedro Alves, Andrew Burgess, gdb-patches On 2021-09-24 10:06 a.m., Pedro Alves wrote: > On 2021-09-24 2:40 p.m., Simon Marchi via Gdb-patches wrote: >> On 2021-09-24 9:16 a.m., Andrew Burgess wrote: >>> It has been pointed out to me on IRC (thanks Simon), that this issue >>> is not GCC, but ccache: >>> >>> https://github.com/ccache/ccache/issues/738#issuecomment-740133374 >>> >>> So this patch certainly shouldn't go in as it is currently written. >>> >>> It's still pretty annoying seeing those warnings though, so I wonder >>> if we can consider having a work around for this ccache issue in the >>> GDB configure scripts? >>> >>> Maybe something as simple as setting CCACHE_DISABLE in the environment >>> prior to running the AM_GDB_WARNINGS checks? >>> >>> All ideas welcome... >> >> Either way would be fine with me: >> >> - to use AC_LINK_IFELSE all the time (I don't think the execution time >> would be significantly higher) >> - to set CCACHE_DISABLE during the execution of AM_GDB_WARNINGS > > Does working around this in configure tests still mean that when using ccache > for really building gdb, ccache will still misreorder arguments and thus > potentially a -Wmissing-prototypes warning would not be turned into an error? I think it's only the "-Wmissing-prototypes is useless in C++" warning that has this order problem. If you were compiling something in C and was missing a prototype, that warning would be not be affected by the order bug (although I haven't tried). By working around in the problem in configure, that means -Wmissing-prototypes will not be present when compiling with GCC (as it does nothing in C++), so there's nothing to miss here. > So, here's another option, I think: > > #3 - drop -Wmissing-prototypes completely. > > As the GCC warning says, > > cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ > > it's only valid for C, not C++. Do we compile anything with a C compiler nowadays? It's there because it does something for clang in C++, see: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a0761e34f054767de6d6389929d27e9015fb299b If we find that the rationale for having it there isn't valid anymore, we can remove it. Simon ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support 2021-09-24 14:22 ` Simon Marchi via Gdb-patches @ 2021-09-24 14:30 ` Pedro Alves 2021-09-24 14:55 ` Simon Marchi via Gdb-patches 0 siblings, 1 reply; 10+ messages in thread From: Pedro Alves @ 2021-09-24 14:30 UTC (permalink / raw) To: Simon Marchi, Andrew Burgess, gdb-patches On 2021-09-24 3:22 p.m., Simon Marchi wrote: > > > On 2021-09-24 10:06 a.m., Pedro Alves wrote: >> On 2021-09-24 2:40 p.m., Simon Marchi via Gdb-patches wrote: >>> On 2021-09-24 9:16 a.m., Andrew Burgess wrote: >>>> It has been pointed out to me on IRC (thanks Simon), that this issue >>>> is not GCC, but ccache: >>>> >>>> https://github.com/ccache/ccache/issues/738#issuecomment-740133374 >>>> >>>> So this patch certainly shouldn't go in as it is currently written. >>>> >>>> It's still pretty annoying seeing those warnings though, so I wonder >>>> if we can consider having a work around for this ccache issue in the >>>> GDB configure scripts? >>>> >>>> Maybe something as simple as setting CCACHE_DISABLE in the environment >>>> prior to running the AM_GDB_WARNINGS checks? >>>> >>>> All ideas welcome... >>> >>> Either way would be fine with me: >>> >>> - to use AC_LINK_IFELSE all the time (I don't think the execution time >>> would be significantly higher) >>> - to set CCACHE_DISABLE during the execution of AM_GDB_WARNINGS >> >> Does working around this in configure tests still mean that when using ccache >> for really building gdb, ccache will still misreorder arguments and thus >> potentially a -Wmissing-prototypes warning would not be turned into an error? > > I think it's only the "-Wmissing-prototypes is useless in C++" warning > that has this order problem. If you were compiling something in C and > was missing a prototype, that warning would be not be affected by the > order bug (although I haven't tried). > > By working around in the problem in configure, that means > -Wmissing-prototypes will not be present when compiling with GCC (as it > does nothing in C++), so there's nothing to miss here. > >> So, here's another option, I think: >> >> #3 - drop -Wmissing-prototypes completely. >> >> As the GCC warning says, >> >> cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ >> >> it's only valid for C, not C++. Do we compile anything with a C compiler nowadays? > > It's there because it does something for clang in C++, see: > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a0761e34f054767de6d6389929d27e9015fb299b > > If we find that the rationale for having it there isn't valid anymore, > we can remove it. How about skipping checking for -Wmissing-prototypes support if compiling with gcc then? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support 2021-09-24 14:30 ` Pedro Alves @ 2021-09-24 14:55 ` Simon Marchi via Gdb-patches 2021-09-24 15:09 ` Pedro Alves 0 siblings, 1 reply; 10+ messages in thread From: Simon Marchi via Gdb-patches @ 2021-09-24 14:55 UTC (permalink / raw) To: Pedro Alves, Andrew Burgess, gdb-patches > How about skipping checking for -Wmissing-prototypes support if compiling with gcc then? The other solutions seemed a bit better to me, since they were adding less special cases and complexity, but in the end I don't really mind, as long as it works. Simon ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support 2021-09-24 14:55 ` Simon Marchi via Gdb-patches @ 2021-09-24 15:09 ` Pedro Alves 0 siblings, 0 replies; 10+ messages in thread From: Pedro Alves @ 2021-09-24 15:09 UTC (permalink / raw) To: Simon Marchi, Andrew Burgess, gdb-patches On 2021-09-24 3:55 p.m., Simon Marchi wrote: >> How about skipping checking for -Wmissing-prototypes support if compiling with gcc then? > > The other solutions seemed a bit better to me, since they were adding > less special cases and complexity, but in the end I don't really mind, > as long as it works. Imagine two different sets of warnings, warnings about "bad1", and warnings about "bad2" with "bad1" and "bad2" being completely unrelated. You want to enable warnings about "bad1", and not about "bad2". The problem is that both compilers A and B accept a "-Wfoo" switch, and that switch enables "bad1" warnings on compiler A, and "bad2" warnings on compiler B. How do you handle this? Well, the most obvious fix would be to make it compiler specific, right? Forcing linking or doing something special for ccache seems like special casing to me too. More than a compiler check from the angle above, from the view that not enabling the warning on GCC is just something that makes sense on its own. In the end I don't mind which approach is taken either. Opinions were asked, and I gave mine. :-) ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCHv2] gdbsupport: better detection of -Wmissing-prototypes support 2021-09-24 12:29 [PATCH] gdbsupport: better detection of -Wmissing-prototypes support Andrew Burgess 2021-09-24 13:16 ` Andrew Burgess @ 2021-09-24 15:14 ` Andrew Burgess 2021-10-25 14:50 ` Simon Marchi via Gdb-patches 1 sibling, 1 reply; 10+ messages in thread From: Andrew Burgess @ 2021-09-24 15:14 UTC (permalink / raw) To: gdb-patches I know there's still some discussion about what the best way to deal with this might be, but here's an updated patch that just uses AM_LINK_IFELSE for all the AM_GDB_WARNINGS tests. If the preference is for a different approach, I'm happy to go with something else instead. Thanks, Andrew --- When building using ccache I notice lots of warnings like this while building GDB: cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ This is a little strange as the configure macro, AM_GDB_WARNINGS, should figure out which warning flags are valid, and which are not. It turns out that there's an issue with ccache and gcc relating to option ordering, these are described here: https://github.com/ccache/ccache/issues/738 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87161 Basically, ccache reorders some command line options, so this: -Werror -Wmissing-prototypes becomes: -Wmissing-prototypes -Werror And, so, when g++ sees the -Wmissing-prototypes option, it has not yet seen -Werror, and as -Wmissing-prototypes is not supported in g++, a warning is immediately issued. What this means is that when the AM_GDB_WARNINGS macro tries to test if -Wmissing-prototypes is support on g++ (and if the user is using ccache), then all the macro ever sees is a warning, not an error, and so the macro assumes that -Wmissing-prototypes is supported. Now the AM_GDB_WARNINGS makes use of AM_COMPILE_IFELSE to compile a test file to object format. IF instead we use AM_LINK_IFELSE then the compiler will be invoked to take the source file all the way to executable format. Now, when ccache sees the compiler invoked to do a full build (to executable), ccache does not activate, and there is not command line flag reordering, and so, we get an error for -Wmissing-prototypes rather than a warning, and this flag will not be used (for g++). --- gdb/configure | 26 ++++++++++++++++++++++---- gdbserver/configure | 26 ++++++++++++++++++++++---- gdbsupport/configure | 26 ++++++++++++++++++++++---- gdbsupport/warning.m4 | 20 ++++++++++++++++++-- 4 files changed, 84 insertions(+), 14 deletions(-) diff --git a/gdb/configure b/gdb/configure index f0b1af4a6ea..41df4d22b88 100755 --- a/gdb/configure +++ b/gdb/configure @@ -16993,6 +16993,22 @@ $as_echo_n "checking compiler warning flags... " >&6; } CFLAGS="$CFLAGS -Werror $wtest" saved_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -Werror $wtest" + # In the following tests we use AC_LINK_IFELSE rather than + # AC_COMPILE_IFELSE, this works around this issue when + # using ccache: https://github.com/ccache/ccache/issues/738. + # + # Basically, ccache will reorder -Werror with respect to + # other command line options, placing -Werror after other + # options. If the problem with the command line option is + # that it is not supported in the current language + # (e.g. -Wmissing-prototypes for g++), then this means + # that you'll get a warning and not an error about the + # option. + # + # However, if we perform a full link then ccache will not + # kick in (ccache only activates when compiling to object + # format), and so the options are not reordered, and we'll + # get an error for any unsupported options. if test "x$w" = "x-Wunused-variable"; then # Check for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38958, # fixed in GCC 4.9. This test is derived from the gdb @@ -17012,10 +17028,11 @@ const scoped_restore_base &b = scoped_restore_tmpl(); return 0; } _ACEOF -if ac_fn_cxx_try_compile "$LINENO"; then : +if ac_fn_cxx_try_link "$LINENO"; then : WARN_CFLAGS="${WARN_CFLAGS} $w" fi -rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext else cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ @@ -17028,10 +17045,11 @@ main () return 0; } _ACEOF -if ac_fn_cxx_try_compile "$LINENO"; then : +if ac_fn_cxx_try_link "$LINENO"; then : WARN_CFLAGS="${WARN_CFLAGS} $w" fi -rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext fi CFLAGS="$saved_CFLAGS" CXXFLAGS="$saved_CXXFLAGS" diff --git a/gdbserver/configure b/gdbserver/configure index b227167e270..23f1fc4d022 100755 --- a/gdbserver/configure +++ b/gdbserver/configure @@ -9743,6 +9743,22 @@ $as_echo_n "checking compiler warning flags... " >&6; } CFLAGS="$CFLAGS -Werror $wtest" saved_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -Werror $wtest" + # In the following tests we use AC_LINK_IFELSE rather than + # AC_COMPILE_IFELSE, this works around this issue when + # using ccache: https://github.com/ccache/ccache/issues/738. + # + # Basically, ccache will reorder -Werror with respect to + # other command line options, placing -Werror after other + # options. If the problem with the command line option is + # that it is not supported in the current language + # (e.g. -Wmissing-prototypes for g++), then this means + # that you'll get a warning and not an error about the + # option. + # + # However, if we perform a full link then ccache will not + # kick in (ccache only activates when compiling to object + # format), and so the options are not reordered, and we'll + # get an error for any unsupported options. if test "x$w" = "x-Wunused-variable"; then # Check for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38958, # fixed in GCC 4.9. This test is derived from the gdb @@ -9762,10 +9778,11 @@ const scoped_restore_base &b = scoped_restore_tmpl(); return 0; } _ACEOF -if ac_fn_cxx_try_compile "$LINENO"; then : +if ac_fn_cxx_try_link "$LINENO"; then : WARN_CFLAGS="${WARN_CFLAGS} $w" fi -rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext else cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ @@ -9778,10 +9795,11 @@ main () return 0; } _ACEOF -if ac_fn_cxx_try_compile "$LINENO"; then : +if ac_fn_cxx_try_link "$LINENO"; then : WARN_CFLAGS="${WARN_CFLAGS} $w" fi -rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext fi CFLAGS="$saved_CFLAGS" CXXFLAGS="$saved_CXXFLAGS" diff --git a/gdbsupport/configure b/gdbsupport/configure index a9dd02c5b72..43c7b06d135 100755 --- a/gdbsupport/configure +++ b/gdbsupport/configure @@ -10228,6 +10228,22 @@ $as_echo_n "checking compiler warning flags... " >&6; } CFLAGS="$CFLAGS -Werror $wtest" saved_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -Werror $wtest" + # In the following tests we use AC_LINK_IFELSE rather than + # AC_COMPILE_IFELSE, this works around this issue when + # using ccache: https://github.com/ccache/ccache/issues/738. + # + # Basically, ccache will reorder -Werror with respect to + # other command line options, placing -Werror after other + # options. If the problem with the command line option is + # that it is not supported in the current language + # (e.g. -Wmissing-prototypes for g++), then this means + # that you'll get a warning and not an error about the + # option. + # + # However, if we perform a full link then ccache will not + # kick in (ccache only activates when compiling to object + # format), and so the options are not reordered, and we'll + # get an error for any unsupported options. if test "x$w" = "x-Wunused-variable"; then # Check for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38958, # fixed in GCC 4.9. This test is derived from the gdb @@ -10247,10 +10263,11 @@ const scoped_restore_base &b = scoped_restore_tmpl(); return 0; } _ACEOF -if ac_fn_cxx_try_compile "$LINENO"; then : +if ac_fn_cxx_try_link "$LINENO"; then : WARN_CFLAGS="${WARN_CFLAGS} $w" fi -rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext else cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ @@ -10263,10 +10280,11 @@ main () return 0; } _ACEOF -if ac_fn_cxx_try_compile "$LINENO"; then : +if ac_fn_cxx_try_link "$LINENO"; then : WARN_CFLAGS="${WARN_CFLAGS} $w" fi -rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext fi CFLAGS="$saved_CFLAGS" CXXFLAGS="$saved_CXXFLAGS" diff --git a/gdbsupport/warning.m4 b/gdbsupport/warning.m4 index 46036fa461e..53dc59bc490 100644 --- a/gdbsupport/warning.m4 +++ b/gdbsupport/warning.m4 @@ -135,11 +135,27 @@ then CFLAGS="$CFLAGS -Werror $wtest" saved_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -Werror $wtest" + # In the following tests we use AC_LINK_IFELSE rather than + # AC_COMPILE_IFELSE, this works around this issue when + # using ccache: https://github.com/ccache/ccache/issues/738. + # + # Basically, ccache will reorder -Werror with respect to + # other command line options, placing -Werror after other + # options. If the problem with the command line option is + # that it is not supported in the current language + # (e.g. -Wmissing-prototypes for g++), then this means + # that you'll get a warning and not an error about the + # option. + # + # However, if we perform a full link then ccache will not + # kick in (ccache only activates when compiling to object + # format), and so the options are not reordered, and we'll + # get an error for any unsupported options. if test "x$w" = "x-Wunused-variable"; then # Check for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38958, # fixed in GCC 4.9. This test is derived from the gdb # source code that triggered this bug in GCC. - AC_COMPILE_IFELSE( + AC_LINK_IFELSE( [AC_LANG_PROGRAM( [struct scoped_restore_base {}; struct scoped_restore_tmpl : public scoped_restore_base { @@ -151,7 +167,7 @@ then [] ) else - AC_COMPILE_IFELSE( + AC_LINK_IFELSE( [AC_LANG_PROGRAM([], [])], [WARN_CFLAGS="${WARN_CFLAGS} $w"], [] -- 2.25.4 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCHv2] gdbsupport: better detection of -Wmissing-prototypes support 2021-09-24 15:14 ` [PATCHv2] " Andrew Burgess @ 2021-10-25 14:50 ` Simon Marchi via Gdb-patches 0 siblings, 0 replies; 10+ messages in thread From: Simon Marchi via Gdb-patches @ 2021-10-25 14:50 UTC (permalink / raw) To: Andrew Burgess, gdb-patches On 2021-09-24 11:14, Andrew Burgess wrote: > I know there's still some discussion about what the best way to deal > with this might be, but here's an updated patch that just uses > AM_LINK_IFELSE for all the AM_GDB_WARNINGS tests. > > If the preference is for a different approach, I'm happy to go with > something else instead. > > Thanks, > Andrew Hi Andrew, I just stumbled on this while scrolling my inbox. I'd be happy for you to merge any version of this :). Simon ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-10-25 14:50 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-24 12:29 [PATCH] gdbsupport: better detection of -Wmissing-prototypes support Andrew Burgess 2021-09-24 13:16 ` Andrew Burgess 2021-09-24 13:40 ` Simon Marchi via Gdb-patches 2021-09-24 14:06 ` Pedro Alves 2021-09-24 14:22 ` Simon Marchi via Gdb-patches 2021-09-24 14:30 ` Pedro Alves 2021-09-24 14:55 ` Simon Marchi via Gdb-patches 2021-09-24 15:09 ` Pedro Alves 2021-09-24 15:14 ` [PATCHv2] " Andrew Burgess 2021-10-25 14:50 ` Simon Marchi via Gdb-patches
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox