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

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

[Yodel Eldar]

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/

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
+
 if ! test -e "$source_path/.git"
 then
     git_submodules_action="validate"
-- 
2.53.0

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

[Daniel P. Berrangé]

On Mon, Mar 02, 2026 at 07:20:54PM -0600, 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.

In the bug 

> 
> 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/
> 
> 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 don't think it is acceptable to override the user's choice of compiler,
and I'm not really a fan of auto-changing use of -Werror either.  

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.

So IMHO the issue above is not a bug - it is sanitizers doing what they
are expected to do.

If we want to inform the user of the possible fallout, then it would
suffice to print a warning message at the end of meson:

  if sanitizers and -Werror
  
     warning("Note: sanitizers may produce false positives."
             "It is recommended to disable -Werror if requiring"
	     "a complete build of QEMU without errors")

  endif

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 :|

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

[Thomas Huth]

On 03/03/2026 02.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.
That's already a very big change and might be rather confusing for the users 
that expected configure to do something different.

If we really feel like we should silence this error in the old rtl8139 code, 
I think we should do it locally there with some pragmas like this:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-overflow"

     ... bad code ...

#pragma GCC diagnostic pop

WDYT?

  Thomas

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

[Peter Maydell]

On Tue, 3 Mar 2026 at 08:41, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Mon, Mar 02, 2026 at 07:20:54PM -0600, 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.
>
> In the bug
>
> >
> > 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/
> >
> > 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

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

[Daniel P. Berrangé]

On Tue, Mar 03, 2026 at 09:36:45AM +0000, Peter Maydell wrote:
> On Tue, 3 Mar 2026 at 08:41, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Mon, Mar 02, 2026 at 07:20:54PM -0600, 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.
> >
> > In the bug
> >
> > >
> > > 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/
> > >
> > > 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.

Oh, so you mean CLang errors from sanitizers are not influenced by
the use of -Werror ?

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 :|

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

[Peter Maydell]

On Tue, 3 Mar 2026 at 10:01, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Tue, Mar 03, 2026 at 09:36:45AM +0000, Peter Maydell wrote:
> > On Tue, 3 Mar 2026 at 08:41, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > 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.
>
> Oh, so you mean CLang errors from sanitizers are not influenced by
> the use of -Werror ?

I mean that (in my understanding) whether you use -fsanitizer=... or not
does not affect the set of compile time warnings that clang emits.
Sanitizer errors themselves are runtime ones and the controls on what
the runtime does when it hits a sanitizer error are entirely different.

This specific case we're seeing with the rtl8139 code is not
a sanitizer warning, it's a plain old -Wstringop-overflow
compiler warning. The sanitizer only affects things because in gcc
the sanitizer pass is in a place in codegen which happens before some
warnings are emitted, so the things it does to the IR can affect
what warnings are generated.

thanks
-- PMM

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

[Yodel Eldar]

+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/
> 
> 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
> +
>   if ! test -e "$source_path/.git"
>   then
>       git_submodules_action="validate"

We could treat the rtl8139 as a one-off by carving out the
offending code with a GCC pragma or finagling GCC into cooperation
by substituting eth_payload_data with the expression assigned to it
(thank you, Thomas and Daniel, respectively); indeed, AFAICT the
rtl8139 is currently the only code that triggers the GCC bug
(and is overdue for a refactor/cleanup), so it's tempting to go with
either of these helpful suggestions; *however*, until the GCC team
fixes their buggy pairing between sanitizer and -Werror
(a pairing that they themselves disavow [1]), IMHO there's a
significant risk of recurrence if we went with either option, and
it's not clear to me whether reviewers will be able easily spot the
next one before it's too late (post-acceptance).

That said, I fully share Daniel's concerns about "overriding the
user's choice of compiler"; so, what if we instead moved the
sanitizer check into the existing "Preferred compiler" section
in configure, such that we only set cc=clang when the user hasn't
explicitly specified CC/CXX (diff below)? Note: there's already
precedent for this with the Obj-C compiler [2].

I'm definitely onboard with Daniel's warning message in meson whenever
the user: 1) explicitly opts for gcc/g++, 2) enables sanitizers, and 3)
-Werror is enabled. At the risk of overengineering, though, what if we
made it an error message instead, and gave users an escape hatch like
`--force-werror-sanitizers` (name TBD)? I can see that being too much,
but it may prevent some grief if they missed the warning, and the build
breaks several minutes later. WDYT? It's not included in the diff below,
but I'll gladly add it to v3 if there's interest; if not, I'll go with
the warning message as suggested.

Thanks,
Yodel

[1] https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html (Peter)
[2] 
https://gitlab.com/qemu-project/qemu/-/blob/master/configure?ref_type=heads#L302-315

-- >8 --

diff --git a/configure b/configure
index 5e114acea2..861723b0a4 100755
--- a/configure
+++ b/configure
@@ -245,6 +245,12 @@ for opt do
    ;;
    --wasm64-32bit-address-limit) wasm64_memory64="2"
    ;;
+  --enable-asan) use_sanitizers="yes"
+  ;;
+  --enable-tsan) use_sanitizers="yes"
+  ;;
+  --enable-safe-stack) use_sanitizers="yes"
+  ;;
    esac
  done

@@ -286,15 +292,25 @@ static="no"
  # Preferred compiler:
  #  ${CC} (if set)
  #  ${cross_prefix}gcc (if cross-prefix specified)
-#  system compiler
+#  clang if sanitizer requested, otherwise system compiler
  if test -z "${CC}${cross_prefix}"; then
-  cc="cc"
+  if test "$use_sanitizers" = "yes" && has clang; then
+    cc=clang
+    echo "Sanitizer requested: setting cc to clang"
+  else
+    cc="cc"
+  fi
  else
    cc="${CC-${cross_prefix}gcc}"
  fi

  if test -z "${CXX}${cross_prefix}"; then
-  cxx="c++"
+  if test "$use_sanitizers" = "yes" && has clang; then
+    cxx=clang++
+    echo "Sanitizer requested: setting cxx to clang++"
+  else
+    cxx="c++"
+  fi
  else
    cxx="${CXX-${cross_prefix}g++}"
  fi

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

[Thomas Huth]

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/
>>
>> 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
>> +
>>   if ! test -e "$source_path/.git"
>>   then
>>       git_submodules_action="validate"
> 
> We could treat the rtl8139 as a one-off by carving out the
> offending code with a GCC pragma or finagling GCC into cooperation
> by substituting eth_payload_data with the expression assigned to it
> (thank you, Thomas and Daniel, respectively); indeed, AFAICT the
> rtl8139 is currently the only code that triggers the GCC bug
> (and is overdue for a refactor/cleanup), so it's tempting to go with
> either of these helpful suggestions; *however*, until the GCC team
> fixes their buggy pairing between sanitizer and -Werror
> (a pairing that they themselves disavow [1]), IMHO there's a
> significant risk of recurrence if we went with either option, and
> it's not clear to me whether reviewers will be able easily spot the
> next one before it's too late (post-acceptance).
> 
> That said, I fully share Daniel's concerns about "overriding the
> user's choice of compiler"; so, what if we instead moved the
> sanitizer check into the existing "Preferred compiler" section
> in configure, such that we only set cc=clang when the user hasn't
> explicitly specified CC/CXX (diff below)? Note: there's already
> precedent for this with the Obj-C compiler [2].
> 
> I'm definitely onboard with Daniel's warning message in meson whenever
> the user: 1) explicitly opts for gcc/g++, 2) enables sanitizers, and 3)
> -Werror is enabled. At the risk of overengineering, though, what if we
> made it an error message instead, and gave users an escape hatch like
> `--force-werror-sanitizers` (name TBD)? I can see that being too much,
> but it may prevent some grief if they missed the warning, and the build
> breaks several minutes later. WDYT? It's not included in the diff below,
> but I'll gladly add it to v3 if there's interest; if not, I'll go with
> the warning message as suggested.

I think I would rather avoid another switch like --force-werror-sanitizers 
and making it a hard error instead of a warning. Think of the point in time 
when GCC fixed their bug - if someone then wants to compile QEMU with that 
new GCC, this becomes rather obstructive.

Alternative idea: What about adding -Wno-stringop-overflow to the CFLAGS 
when we detect the problematic situation (GCC + sanitizers + -Werror)? Then 
the build could also continue with GCC without running into the problem.

  Thomas

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

[Daniel P. Berrangé]

On Tue, Mar 03, 2026 at 07:08:25PM -0600, 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/
> > 
> > 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
> > +
> >   if ! test -e "$source_path/.git"
> >   then
> >       git_submodules_action="validate"
> 
> We could treat the rtl8139 as a one-off by carving out the
> offending code with a GCC pragma or finagling GCC into cooperation
> by substituting eth_payload_data with the expression assigned to it
> (thank you, Thomas and Daniel, respectively); indeed, AFAICT the
> rtl8139 is currently the only code that triggers the GCC bug
> (and is overdue for a refactor/cleanup), so it's tempting to go with
> either of these helpful suggestions; *however*, until the GCC team
> fixes their buggy pairing between sanitizer and -Werror
> (a pairing that they themselves disavow [1]), IMHO there's a
> significant risk of recurrence if we went with either option, and
> it's not clear to me whether reviewers will be able easily spot the
> next one before it's too late (post-acceptance).

There is a risk, but given that we've only got 1 example across
the QEMU codebase, I don't think I'd classify that as significant.
If we already had 10+ locations where it hit, then that would be
a different story

As long as the number of situations where we hit this in QEMU
remains low (say < 5), then I think a targetted use of Pragmas
to temp disable warnings is satisfactory to deal with it.

> I'm definitely onboard with Daniel's warning message in meson whenever
> the user: 1) explicitly opts for gcc/g++, 2) enables sanitizers, and 3)
> -Werror is enabled. At the risk of overengineering, though, what if we
> made it an error message instead, and gave users an escape hatch like
> `--force-werror-sanitizers` (name TBD)? I can see that being too much,
> but it may prevent some grief if they missed the warning, and the build
> breaks several minutes later. WDYT? It's not included in the diff below,
> but I'll gladly add it to v3 if there's interest; if not, I'll go with
> the warning message as suggested.
> 
> Thanks,
> Yodel
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html (Peter)
> [2] https://gitlab.com/qemu-project/qemu/-/blob/master/configure?ref_type=heads#L302-315
> 


> @@ -286,15 +292,25 @@ static="no"
>  # Preferred compiler:
>  #  ${CC} (if set)
>  #  ${cross_prefix}gcc (if cross-prefix specified)
> -#  system compiler
> +#  clang if sanitizer requested, otherwise system compiler
>  if test -z "${CC}${cross_prefix}"; then
> -  cc="cc"
> +  if test "$use_sanitizers" = "yes" && has clang; then
> +    cc=clang
> +    echo "Sanitizer requested: setting cc to clang"

I really don't want to see us changing compiler choice as a side
effect of enabling sanitizers.

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 :|

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

[Yodel Eldar]

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/
>>>
>>> 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
>>> +
>>>   if ! test -e "$source_path/.git"
>>>   then
>>>       git_submodules_action="validate"
>>
>> We could treat the rtl8139 as a one-off by carving out the
>> offending code with a GCC pragma or finagling GCC into cooperation
>> by substituting eth_payload_data with the expression assigned to it
>> (thank you, Thomas and Daniel, respectively); indeed, AFAICT the
>> rtl8139 is currently the only code that triggers the GCC bug
>> (and is overdue for a refactor/cleanup), so it's tempting to go with
>> either of these helpful suggestions; *however*, until the GCC team
>> fixes their buggy pairing between sanitizer and -Werror
>> (a pairing that they themselves disavow [1]), IMHO there's a
>> significant risk of recurrence if we went with either option, and
>> it's not clear to me whether reviewers will be able easily spot the
>> next one before it's too late (post-acceptance).
>>
>> That said, I fully share Daniel's concerns about "overriding the
>> user's choice of compiler"; so, what if we instead moved the
>> sanitizer check into the existing "Preferred compiler" section
>> in configure, such that we only set cc=clang when the user hasn't
>> explicitly specified CC/CXX (diff below)? Note: there's already
>> precedent for this with the Obj-C compiler [2].
>>
>> I'm definitely onboard with Daniel's warning message in meson whenever
>> the user: 1) explicitly opts for gcc/g++, 2) enables sanitizers, and 3)
>> -Werror is enabled. At the risk of overengineering, though, what if we
>> made it an error message instead, and gave users an escape hatch like
>> `--force-werror-sanitizers` (name TBD)? I can see that being too much,
>> but it may prevent some grief if they missed the warning, and the build
>> breaks several minutes later. WDYT? It's not included in the diff below,
>> but I'll gladly add it to v3 if there's interest; if not, I'll go with
>> the warning message as suggested.
> 
> I think I would rather avoid another switch like --force-werror- 
> sanitizers and making it a hard error instead of a warning. Think of the 
> point in time when GCC fixed their bug - if someone then wants to 
> compile QEMU with that new GCC, this becomes rather obstructive.
> 

A good point I had not considered, though it may favor the hard error:
if GCC resolves the bug on their end while we've got a gate (with a
switch) around it, we may hear the good news sooner, because of the
increased visibility (or obstructiveness); thus, we may be better
situated to promptly tear the gate down if/when that time comes as
compared to a missable warning that may get ignored well after GCC
releases an immune version.

Furthermore, I think the timeliness concern will apply to most
solutions, because the issue stems from an external dependency, and
any workaround will become redundant upon upstream resolution.

> Alternative idea: What about adding -Wno-stringop-overflow to the CFLAGS 
> when we detect the problematic situation (GCC + sanitizers + -Werror)? 
> Then the build could also continue with GCC without running into the 
> problem.
> 

This seems like a major improvement over local pragmas insofar as it
will prevent future occurrences of -Wstringop-overflow false positives,
but over time this may end up growing into a denylist of all of the
warning flags that confuse GCC + sanitizers, and it could be painful
iteratively expanding that list, because we might catch the triggers
ex post facto.

Moreover, if my reading of Peter's description of the GCC bug is
correct [1], then my guess is that a fix may require a nontrivial
redesign that won't be easily backportable for them, so we may end up
in a situation where we also have to account for the user's GCC version
to judiciously apply the piecemeal exclusion of warning flags to only
the versions that are unable to handle them correctly, and that has the
potential of getting messy pretty quickly (unless we decide to treat
all versions the same, or have a cutoff for supported versions).

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.

That said, selecting a compiler on behalf of users, as I've proposed,
might subvert environmental expectations and cause problems for them.
Furthermore, my concerns remain largely speculative; so, I'd like to
further monitor the bug to see how it develops upstream GCC.
Thus, I'm formally withdrawing the patch for now.

Thank you to Peter, Thomas, and Daniel for the lively discussion!

Regards,
Yodel

[1] 
https://lore.kernel.org/qemu-devel/CAFEAcA_nCSah+orZrMvsit=iWWp8o9J_Y8Fg7sMJP7XeV0_GBg@mail.gmail.com/

>   Thomas
> 
> 

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

[Daniel P. Berrangé]

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 :|

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

[Peter Maydell]

On Thu, 5 Mar 2026 at 10:18, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Wed, Mar 04, 2026 at 05:14:47PM -0600, Yodel Eldar wrote:
> > 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.

Mmm. I guess I'm coming around to the idea that we should put in
the workaround you mentiened in the other thread, plus a comment
explaining why and linking to the gcc bugs.

There is a difference here in that here gcc is explicitly
documenting that they're going to produce false positives
(a.k.a "we know our implementation is buggy here"). But as you
say, if there really is just this one place in our code where
we have to work around this, it's probably easiest to just do that.

thanks
-- PMM