Patchwork configure: Disable (clang) initializer-overrides warnings

login
register
mail settings
Submitter Peter Maydell
Date Oct. 14, 2012, 8 p.m.
Message ID <1350244839-16875-1-git-send-email-peter.maydell@linaro.org>
Download mbox | patch
Permalink /patch/191389/
State New
Headers show

Comments

Peter Maydell - Oct. 14, 2012, 8 p.m.
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(+)
Peter Maydell - Oct. 24, 2012, 12:31 p.m.
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
Blue Swirl - Oct. 27, 2012, 4:51 p.m.
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
>
Igor Mitsyanko - Oct. 27, 2012, 8:32 p.m.
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
>>
>
>
Peter Maydell - Oct. 27, 2012, 9:12 p.m.
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
Stefan Weil - Oct. 27, 2012, 9:24 p.m.
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
Peter Maydell - Oct. 27, 2012, 9:35 p.m.
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
Stefan Weil - Oct. 27, 2012, 9:46 p.m.
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

Patch

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,