Re: [Qemu-devel] [PATCH] configure: Disable (clang) initializer-overrides warnings

[Stefan Weil <sw@weilnetz.de>]

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