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 <[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. > > > > > > > > Link to RFCv1: > > > > https://lore.kernel.org/qemu-devel/20260302210039.261325-1- > > > > [email protected]/ > > > > > > > > Link to mentioned discussion: > > > > https://lore.kernel.org/qemu-devel/ > > > > cafeaca88hc4usgpupxbwpben0tw26159kpn7jx2j9erba5d...@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 :|
