Re: [RFC PATCH v2] configure: Use clang for sanitizer builds or disable Werror

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Mar 04, 2026 at 05:14:47PM -0600, Yodel Eldar wrote:
> On 04/03/2026 01:38, Thomas Huth wrote:
> > On 04/03/2026 02.08, Yodel Eldar wrote:
> > > +Daniel (thanks for your comments)
> > > 
> > > On 02/03/2026 19:20, Yodel Eldar wrote:
> > > > From: Yodel Eldar <yodel.eldar@yodel.dev>
> > > > 
> > > > 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 <peter.maydell@linaro.org>
> > > > Signed-off-by: Yodel Eldar <yodel.eldar@yodel.dev>
> > > > ---
> > > > 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.
> > > > 
> > > > Link to RFCv1:
> > > > https://lore.kernel.org/qemu-devel/20260302210039.261325-1-
> > > > yodel.eldar@yodel.dev/
> > > > 
> > > > Link to mentioned discussion:
> > > > https://lore.kernel.org/qemu-devel/
> > > > CAFEAcA88hc4UsgpuPXBWpbeN0tW26159kPn7jx2J9erBA5DLBw@mail.gmail.com/

snip

> In that regard, Daniel's substitution method would fare better, but it
> doesn't prevent build breakage before they occur, it may only apply to
> stringop-overflow false positives (TBD), and it may come at the cost
> of code clarity or expressiveness.

This is not at all unique to the sanitizers option. Pretty much every
single major GCC release introduces new logic that triggers compiler
warnings in QEMU which break the build with -Werror, for both genuine
bugs and new false positives.

If you're using -Werror at all, you have to expect frequent breakage
in the future. We fix the genuine bugs and workaround the false
positives. We already have a number of examples of using
"#pragma GCC diagnostic push" for this purpose across the codebase.
I don't see a strong reason to treat this one sanitizers issue
differently from other false positives we address.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|