All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Yodel Eldar <yodel.eldar@yodel.dev>
Cc: qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Thomas Huth" <thuth@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>
Subject: Re: [RFC PATCH v2] configure: Use clang for sanitizer builds or disable Werror
Date: Tue, 3 Mar 2026 08:41:22 +0000	[thread overview]
Message-ID: <aaadd0B4kP9amEbz@redhat.com> (raw)
In-Reply-To: <20260303012054.484837-1-yodel.eldar@yodel.dev>

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



  reply	other threads:[~2026-03-03  8:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-03  1:20 [RFC PATCH v2] configure: Use clang for sanitizer builds or disable Werror Yodel Eldar
2026-03-03  8:41 ` Daniel P. Berrangé [this message]
2026-03-03  9:36   ` Peter Maydell
2026-03-03 10:01     ` Daniel P. Berrangé
2026-03-03 10:05       ` Peter Maydell
2026-03-03  8:49 ` Thomas Huth
2026-03-04  1:08 ` Yodel Eldar
2026-03-04  7:38   ` Thomas Huth
2026-03-04 23:14     ` Yodel Eldar
2026-03-05 10:18       ` Daniel P. Berrangé
2026-03-05 10:47         ` Peter Maydell
2026-03-04 10:09   ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aaadd0B4kP9amEbz@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=yodel.eldar@yodel.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.