On Tue, 3 Mar 2026 at 08:41, Daniel P. Berrangé <[email protected]> wrote: > > On Mon, Mar 02, 2026 at 07:20:54PM -0600, Yodel Eldar wrote: > > From: Yodel Eldar <[email protected]> > > > > Builds with --enable-{asan,tsan,safe-stack} fail under GCC, so use > > clang if available, otherwise disable the treatment of warnings as > > errors. > > > > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3006 > > Suggested-by: Peter Maydell <[email protected]> > > Signed-off-by: Yodel Eldar <[email protected]> > > --- > > Hi, > > > > The previous version only disabled Werror whenever `--skip-meson` wasn't > > used and the build occurred in a git repo, but this change should > > probably apply to all types of builds. So, let's use meson_option_add > > to globally disable Werror instead; IIUC (and according to my testing), > > this will override the value in config-meson.cross.new. > > > > I'm still not sure if we should be disabling Werror for ubsan, even > > though it's not currently breaking builds with GCC; please let me know > > what you think. > > > > Special thanks to Peter for looking into the cause of the reports around > > this, for sharing the findings, and suggesting approaches to resolve it. > > I couldn't pick one over the other, so I went with using clang when > > available with Werror disable as a fallback; please let me know if you > > think this is an XOR kind of policy decision. > > In the bug > > > > > Link to RFCv1: > > https://lore.kernel.org/qemu-devel/[email protected]/ > > > > Link to mentioned discussion: > > https://lore.kernel.org/qemu-devel/cafeaca88hc4usgpupxbwpben0tw26159kpn7jx2j9erba5d...@mail.gmail.com/ > > > > v2: > > - Fix misnomer in commit message > > - Simplify condition by using the same variable for all sanitizers > > - Use meson_option_add to disable Werror > > > > Thanks, > > Yodel > > --- > > configure | 18 ++++++++++++++++++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/configure b/configure > > index 5e114acea2..e457e8a17d 100755 > > --- a/configure > > +++ b/configure > > @@ -762,6 +762,12 @@ for opt do > > ;; > > --wasm64-32bit-address-limit) > > ;; > > + --enable-asan) use_sanitizer="yes" > > + ;; > > + --enable-tsan) use_sanitizer="yes" > > + ;; > > + --enable-safe-stack) use_sanitizer="yes" > > + ;; > > # everything else has the same name in configure and meson > > --*) meson_option_parse "$opt" "$optarg" > > ;; > > @@ -771,6 +777,18 @@ for opt do > > esac > > done > > > > +if test "$use_sanitizer" = "yes"; then > > + if has clang; then > > + echo "Sanitizer requested: setting compiler suite to clang" > > + cc=clang > > + cxx=clang++ > > + host_cc=clang > > + else > > + echo "Sanitizer requested: disabling Werror for non-clang > > compilers" > > + meson_option_add -Dwerror=false > > + fi > > +fi > > GCC documents the possibility of false positives, but I would consider > that caveat to apply to CLang too. It may simply have different false > positives or at a lower rate.
I'm told that clang/LLVM doesn't have any "middle-end warnings", so it won't have the same problem that the sanitizers might change IR code in a way that results in a warning firing that didn't before. So I think this "sanitizers change warning behaviour" is specific to GCC. > If using sanitizers, it is expected behaviour that there can be false > positives, and if the user doesn't want the build to break as a result > of that, then *the user* can choose to disable -Werror with the suitable > configure warnings. It is expected *for GCC*. I don't think it's expected for LLVM/clang. -- PMM
