Re: [PATCH v2 1/4] meson: hide tsan related warnings

[Thomas Huth <thuth@redhat.com>]

On 15/08/2024 19.54, Peter Maydell wrote:
> On Thu, 15 Aug 2024 at 12:05, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>
>> On Thu, Aug 15, 2024 at 11:12:39AM +0100, Peter Maydell wrote:
>>> On Wed, 14 Aug 2024 at 23:42, Pierrick Bouvier
>>> <pierrick.bouvier@linaro.org> wrote:
>>>>
>>>> When building with gcc-12 -fsanitize=thread, gcc reports some
>>>> constructions not supported with tsan.
>>>> Found on debian stable.
>>>>
>>>> qemu/include/qemu/atomic.h:36:52: error: ‘atomic_thread_fence’ is not supported with ‘-fsanitize=thread’ [-Werror=tsan]
>>>>     36 | #define smp_mb()                     ({ barrier(); __atomic_thread_fence(__ATOMIC_SEQ_CST); })
>>>>        |                                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
>>>> ---
>>>>   meson.build | 10 +++++++++-
>>>>   1 file changed, 9 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/meson.build b/meson.build
>>>> index 81ecd4bae7c..52e5aa95cc0 100644
>>>> --- a/meson.build
>>>> +++ b/meson.build
>>>> @@ -499,7 +499,15 @@ if get_option('tsan')
>>>>                            prefix: '#include <sanitizer/tsan_interface.h>')
>>>>       error('Cannot enable TSAN due to missing fiber annotation interface')
>>>>     endif
>>>> -  qemu_cflags = ['-fsanitize=thread'] + qemu_cflags
>>>> +  tsan_warn_suppress = []
>>>> +  # gcc (>=11) will report constructions not supported by tsan:
>>>> +  # "error: ‘atomic_thread_fence’ is not supported with ‘-fsanitize=thread’"
>>>> +  # https://gcc.gnu.org/gcc-11/changes.html
>>>> +  # However, clang does not support this warning and this triggers an error.
>>>> +  if cc.has_argument('-Wno-tsan')
>>>> +    tsan_warn_suppress = ['-Wno-tsan']
>>>> +  endif
>>>
>>> That last part sounds like a clang bug -- -Wno-foo is supposed
>>> to not be an error on compilers that don't implement -Wfoo for
>>> any value of foo (unless some other warning/error would also
>>> be emitted).
>>
>> -Wno-foo isn't an error, but it is a warning... which we then
>> turn into an error due to -Werror, unless we pass -Wno-unknown-warning-option
>> to clang.
> 
> Which is irritating if you want to be able to blanket say
> '-Wno-silly-compiler-warning' and not see any of that
> warning regardless of compiler version. That's why the
> gcc behaviour is the way it is (i.e. -Wno-such-thingy
> is neither a warning nor an error if it would be the only
> warning/error), and if clang doesn't match it that's a shame.

I thought that Clang would behave the same way as GCC, but apparently it 
does not (anymore?):

$ gcc -Wno-flux-capacitors testprg.c -o testprg
$ clang -Wno-flux-capacitors testprg.c -o testprg
warning: unknown warning option '-Wno-flux-capacitors' 
[-Wunknown-warning-option]
1 warning generated.

  Thomas