| Message ID | 1350244839-16875-1-git-send-email-peter.maydell@linaro.org |
|---|---|
| State | New |
| Headers | show |
On 14 October 2012 21:24, Peter Maydell <peter.maydell@linaro.org> wrote: > On 14 October 2012 21:15, Blue Swirl <blauwirbel@gmail.com> wrote: >> On Sun, Oct 14, 2012 at 8:00 PM, Peter Maydell <peter.maydell@linaro.org> wrote: >>> Blue Swirl previously submitted a patch which enabled this flag >>> (among others): >>> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg04203.html >> >> In my version, Clang flags were separate from GCC flags. I think it >> would be better to run different tests for each compiler in the >> future, that lets GCC avoid Clang flag -ffoobar which does not have >> desirable effect to GCC and vice versa. > > Mmm, but at the moment it's entirely fine to pass both compilers > the same flags, and moreover we actually pass all these flags > to the compiler without checking if it's gcc or not; we just > ask if the compiler will run OK with the flag passed. (I'm not > even sure how you'd determine whether your compiler was gcc > or clang or gcc-llvm or whatever...) This discussion seems to have got stalled. Do you really want to try to add a mechanism for detecting which compiler is being used and applyng different flags for each, given that we don't actually need to do that in this case? -- PMM
Thanks, applied. On Sun, Oct 14, 2012 at 8:00 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > Disable clang's initializer-overrides warnings, as QEMU makes significant > use of the pattern of initializing an array with a range-based default > entry like > [0 ... 0x1ff] = { GPIO_NONE, 0 } > followed by specific entries which override that default, and clang > would otherwise warn "initializer overrides prior initialization of > this subobject" when it encountered the specific entry. > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > --- > This is basically a judgement that our coding style is legitimate > and the compiler is being overly alarmist. I don't think we would > benefit from trying to silence the warnings and I can't think of > a clean way of doing so... > > NB that gcc will happily ignore -Wno-wombat warnings that it doesn't > happen to recognize. (For compilers that don't accept-and-ignore the flag > configure will identify this and not use it.) > > Blue Swirl previously submitted a patch which enabled this flag > (among others): > http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg04203.html > > I haven't found the other two flags in that patch to be required. > > configure | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure b/configure > index 353d788..f78cfc5 100755 > --- a/configure > +++ b/configure > @@ -1187,6 +1187,7 @@ gcc_flags="-Wold-style-declaration -Wold-style-definition -Wtype-limits" > gcc_flags="-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers $gcc_flags" > gcc_flags="-Wmissing-include-dirs -Wempty-body -Wnested-externs $gcc_flags" > gcc_flags="-fstack-protector-all -Wendif-labels $gcc_flags" > +gcc_flags="-Wno-initializer-overrides $gcc_flags" > # Note that we do not add -Werror to gcc_flags here, because that would > # enable it for all configure tests. If a configure test failed due > # to -Werror this would just silently disable some features, > -- > 1.7.11.4 >
On 10/27/2012 8:51 PM, Blue Swirl wrote: > Thanks, applied. > > On Sun, Oct 14, 2012 at 8:00 PM, Peter Maydell <peter.maydell@linaro.org> wrote: >> Disable clang's initializer-overrides warnings, as QEMU makes significant >> use of the pattern of initializing an array with a range-based default >> entry like >> [0 ... 0x1ff] = { GPIO_NONE, 0 } >> followed by specific entries which override that default, and clang >> would otherwise warn "initializer overrides prior initialization of >> this subobject" when it encountered the specific entry. >> >> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> >> --- >> This is basically a judgement that our coding style is legitimate >> and the compiler is being overly alarmist. I don't think we would >> benefit from trying to silence the warnings and I can't think of >> a clean way of doing so... >> >> NB that gcc will happily ignore -Wno-wombat warnings that it doesn't >> happen to recognize. (For compilers that don't accept-and-ignore the flag >> configure will identify this and not use it.) >> I encountered strange behavior of latest mingw gcc, it ignores unrecognized -Wno-wombat options only in case if no other warnings are issued (configure gccflags test doesn't issue any), otherwise I get this: cc1.exe: warning: unrecognized command line option "-Wno-initializer-overrides" [enabled by default] This is probably a bug in mingw GCC (or perhaps I'm using it wrong), but anyway, this makes QEMU mingw build output very noisy. >> Blue Swirl previously submitted a patch which enabled this flag >> (among others): >> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg04203.html >> >> I haven't found the other two flags in that patch to be required. >> >> configure | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/configure b/configure >> index 353d788..f78cfc5 100755 >> --- a/configure >> +++ b/configure >> @@ -1187,6 +1187,7 @@ gcc_flags="-Wold-style-declaration -Wold-style-definition -Wtype-limits" >> gcc_flags="-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers $gcc_flags" >> gcc_flags="-Wmissing-include-dirs -Wempty-body -Wnested-externs $gcc_flags" >> gcc_flags="-fstack-protector-all -Wendif-labels $gcc_flags" >> +gcc_flags="-Wno-initializer-overrides $gcc_flags" >> # Note that we do not add -Werror to gcc_flags here, because that would >> # enable it for all configure tests. If a configure test failed due >> # to -Werror this would just silently disable some features, >> -- >> 1.7.11.4 >> > >
On 27 October 2012 21:32, Igor Mitsyanko <i.mitsyanko@gmail.com> wrote: > I encountered strange behavior of latest mingw gcc, it ignores unrecognized > -Wno-wombat options only in case if no other warnings are issued (configure > gccflags test doesn't issue any), otherwise I get this: > > cc1.exe: warning: unrecognized command line option > "-Wno-initializer-overrides" [enabled by default] > > This is probably a bug in mingw GCC (or perhaps I'm using it wrong), but > anyway, this makes QEMU mingw build output very noisy. It should only warn about that in the case where it's also emitting some other warning message (in which case the idea is to say "and hey maybe this unrecognised no-wombat warning was supposed to suppress this?"), so the build isn't noisy unless it was noisy anyway because of other compile warnings. If we want to actually only pass -Wno-wombat when the gcc knows about it the right approach is to test whether gcc accepts -Wwombat. This is a two-liner patch to configure if we want to do it -- will send a patch in a moment. -- PMM
Am 27.10.2012 22:32, schrieb Igor Mitsyanko: > On 10/27/2012 8:51 PM, Blue Swirl wrote: >> Thanks, applied. >> >> On Sun, Oct 14, 2012 at 8:00 PM, Peter Maydell >> <peter.maydell@linaro.org> wrote: >>> Disable clang's initializer-overrides warnings, as QEMU makes >>> significant >>> use of the pattern of initializing an array with a range-based default >>> entry like >>> [0 ... 0x1ff] = { GPIO_NONE, 0 } >>> followed by specific entries which override that default, and clang >>> would otherwise warn "initializer overrides prior initialization of >>> this subobject" when it encountered the specific entry. >>> >>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> >>> --- >>> This is basically a judgement that our coding style is legitimate >>> and the compiler is being overly alarmist. I don't think we would >>> benefit from trying to silence the warnings and I can't think of >>> a clean way of doing so... >>> >>> NB that gcc will happily ignore -Wno-wombat warnings that it doesn't >>> happen to recognize. (For compilers that don't accept-and-ignore the >>> flag >>> configure will identify this and not use it.) >>> > > I encountered strange behavior of latest mingw gcc, it ignores > unrecognized -Wno-wombat options only in case if no other warnings are > issued (configure gccflags test doesn't issue any), otherwise I get this: > > cc1.exe: warning: unrecognized command line option > "-Wno-initializer-overrides" [enabled by default] > > This is probably a bug in mingw GCC (or perhaps I'm using it wrong), > but anyway, this makes QEMU mingw build output very noisy. This "feature" of gcc is not restricted to MinGW nor to a special version of gcc but can also occur on Linux. Normally, you don't see it there because QEMU compiles without warnings on Linux while there are more or less warnings on MinGW. It looks like we need a better test for compiler options. Here are several possible solutions for this test: * Run the compiler with all compiler options + at least one unsupported option. It will complain and list all invalid options. Remove those from the list. This solution needs a fallback to the current solution if the compiler's error output does not include the invalid options. * Run $cc --help=warnings and look for each warning option in the resulting list. -fstack-protector-all is not a warning option and needs special handling. This solution needs a fallback to the current solution if the compiler does not support --help=warning (clang does not). * Get the compiler and its version and set the options according to the specification. This is more work than the other two solutions. A nice side effect of the first two solutions would be that they can reduce the time needed for configure in the usual environment with gcc (but not with clang). Regards Stefan Weil
On 27 October 2012 22:24, Stefan Weil <sw@weilnetz.de> wrote: > Am 27.10.2012 22:32, schrieb Igor Mitsyanko: >> I encountered strange behavior of latest mingw gcc, it ignores >> unrecognized -Wno-wombat options only in case if no other warnings are >> issued (configure gccflags test doesn't issue any), otherwise I get this: >> >> cc1.exe: warning: unrecognized command line option >> "-Wno-initializer-overrides" [enabled by default] >> >> This is probably a bug in mingw GCC (or perhaps I'm using it wrong), but >> anyway, this makes QEMU mingw build output very noisy. > This "feature" of gcc is not restricted to MinGW nor to a special version of > gcc but can also occur on Linux. Incidentally, I was tangentially involved in getting gcc to adopt this behaviour. The rationale is that it allows you to write straightforward makefiles which use -Werror and also some -Wno-* options without having to add some configure-like step to test whether gcc supports the -Wno-*. If the gcc version you're using doesn't support detecting the presence of wombats in your source code then it will never produce warnings about them, so it's safe for it to treat -Wno-wombat as a no-op. The reason for printing the message if some other warning is also emitted is so the user can spot the case where they accidentally typo'd the -Wno-* option they meant to use to suppress the warning. -- PMM
Am 27.10.2012 23:35, schrieb Peter Maydell: > On 27 October 2012 22:24, Stefan Weil<sw@weilnetz.de> wrote: >> Am 27.10.2012 22:32, schrieb Igor Mitsyanko: >>> I encountered strange behavior of latest mingw gcc, it ignores >>> unrecognized -Wno-wombat options only in case if no other warnings are >>> issued (configure gccflags test doesn't issue any), otherwise I get this: >>> >>> cc1.exe: warning: unrecognized command line option >>> "-Wno-initializer-overrides" [enabled by default] >>> >>> This is probably a bug in mingw GCC (or perhaps I'm using it wrong), but >>> anyway, this makes QEMU mingw build output very noisy. >> This "feature" of gcc is not restricted to MinGW nor to a special version of >> gcc but can also occur on Linux. > > Incidentally, I was tangentially involved in getting gcc to adopt > this behaviour. The rationale is that it allows you to write > straightforward makefiles which use -Werror and also some -Wno-* > options without having to add some configure-like step to test > whether gcc supports the -Wno-*. If the gcc version you're using > doesn't support detecting the presence of wombats in your source > code then it will never produce warnings about them, so it's > safe for it to treat -Wno-wombat as a no-op. The reason for > printing the message if some other warning is also emitted is > so the user can spot the case where they accidentally typo'd > the -Wno-* option they meant to use to suppress the warning. > > -- PMM Nice. Thanks for that explanation. Are there plans to add wombat detection to gcc? :-) Here is the spec: http://upload.wikimedia.org/wikipedia/commons/1/18/Vombatus_ursinus_-Maria_Island_National_Park.jpg Stefan
diff --git a/configure b/configure index 353d788..f78cfc5 100755 --- a/configure +++ b/configure @@ -1187,6 +1187,7 @@ gcc_flags="-Wold-style-declaration -Wold-style-definition -Wtype-limits" gcc_flags="-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers $gcc_flags" gcc_flags="-Wmissing-include-dirs -Wempty-body -Wnested-externs $gcc_flags" gcc_flags="-fstack-protector-all -Wendif-labels $gcc_flags" +gcc_flags="-Wno-initializer-overrides $gcc_flags" # Note that we do not add -Werror to gcc_flags here, because that would # enable it for all configure tests. If a configure test failed due # to -Werror this would just silently disable some features,
Disable clang's initializer-overrides warnings, as QEMU makes significant use of the pattern of initializing an array with a range-based default entry like [0 ... 0x1ff] = { GPIO_NONE, 0 } followed by specific entries which override that default, and clang would otherwise warn "initializer overrides prior initialization of this subobject" when it encountered the specific entry. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- This is basically a judgement that our coding style is legitimate and the compiler is being overly alarmist. I don't think we would benefit from trying to silence the warnings and I can't think of a clean way of doing so... NB that gcc will happily ignore -Wno-wombat warnings that it doesn't happen to recognize. (For compilers that don't accept-and-ignore the flag configure will identify this and not use it.) Blue Swirl previously submitted a patch which enabled this flag (among others): http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg04203.html I haven't found the other two flags in that patch to be required. configure | 1 + 1 file changed, 1 insertion(+)