On Tue, 3 Mar 2026 at 10:01, Daniel P. Berrangé <[email protected]> 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é <[email protected]> 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
