On Fri, Aug 16, 2024 at 07:44:28AM +0200, Thomas Huth wrote: > On 15/08/2024 19.54, Peter Maydell wrote: > > On Thu, 15 Aug 2024 at 12:05, Daniel P. Berrangé <berrange@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> > > > > > --- > > > > > 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?): It is nothing new - clang has behaved this way wrt unknown warning flags for as long as I remember. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|