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
+ qemu_cflags = ['-fsanitize=thread'] + tsan_warn_suppress + qemu_cflags
qemu_ldflags = ['-fsanitize=thread'] + qemu_ldflags
endif
--
2.39.2
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). At any rate, that's how gcc does it (see the paragraph "When an unrecognized warning option ..." in https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html ) and I thought clang did too... thanks -- PMM
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. > At any rate, that's how gcc does it > (see the paragraph "When an unrecognized warning option ..." > in https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html ) > and I thought clang did too... > > thanks > -- PMM > 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 :|
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. thanks -- PMM
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
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@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?): 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 :|
On 8/15/24 10: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. > It's why I chose to implement this using cc.has_argument(), instead of trying to identify compiler/version. > thanks > -- PMM
On 8/15/24 04:05, Daniel P. Berrangé 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. > Right, it's a consequence. >> At any rate, that's how gcc does it >> (see the paragraph "When an unrecognized warning option ..." >> in https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html ) >> and I thought clang did too... >> >> thanks >> -- PMM >> > > With regards, > Daniel
On 15/08/2024 00.41, Pierrick Bouvier 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 > + qemu_cflags = ['-fsanitize=thread'] + tsan_warn_suppress + qemu_cflags > qemu_ldflags = ['-fsanitize=thread'] + qemu_ldflags > endif > Not sure if we should hide these warnings ... they seem to be there for a reason? Paolo, any ideas? Thomas
On 8/15/24 02:50, Thomas Huth wrote: > On 15/08/2024 00.41, Pierrick Bouvier 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 >> + qemu_cflags = ['-fsanitize=thread'] + tsan_warn_suppress + qemu_cflags >> qemu_ldflags = ['-fsanitize=thread'] + qemu_ldflags >> endif >> > > Not sure if we should hide these warnings ... they seem to be there for a > reason? Paolo, any ideas? > This is a new warning added in gcc-11, to prevent that not all constructions are supported by thread sanitizer. This was true before, and will be true after. Basically, manual memory barriers are not supported to model concurrency. We can hardly change something on QEMU side as it's a limitation of tsan itself. Good news is that it does not seem to bring false positives when executing a qemu with tsan. Thus, this patch to ignore this for now. > Thomas >
© 2016 - 2024 Red Hat, Inc.