Re: Is it time to take the middle-end stringop/array warnings out of -Wall?
Matthias Kretz via Gcc <[email protected]>
| Newsgroups | gmane.comp.gcc.devel |
|---|---|
| Organization | GSI Helmholtz Center for Heavy Ion Research |
| Message-ID | <[email protected]> |
Jonathan Wakely via Gcc [Friday, 22 May 2026, 19:51:53 CEST]: > On Fri, 22 May 2026 at 12:49, Matthias Kretz <[email protected]> wrote: > > Jason Merrill via Gcc [Thursday, 21 May 2026, 20:12:01 CEST]: > > > This seems too broad a category; > > > > I think it's a very interesting category. But, with that name, it's not > > very discoverable for users. > > > > My experience with these kinds of warnings (and I implemented library > > precondition checking in a similar manner) is that they can be resolved by > > precondition checking that is visible to the optimizer. I like to think of > > this as "forcing precondition checks to bubble up". > > Sometimes the precondition checks are there, but don't survive IPA, or > something makes them get forgotten before the location of the warning. I've never seen that, even after replacing all __glibcxx_assert in libstdc++ with the precondition macro I showed (i.e. a lot more added middle-end warnings). Hmm, not entirely true: I had to move some the precondition checks out of branches. E.g. if (foo) { __glibcxx_check_precondition(bar); // more code Must be written as __glibcxx_check_precondition(!foo || bar); if (foo) { // more code Do you have an example I could take a look at? > When those warnings happen inside std::string or std::vector, it can > be very difficult to figure out how to provide enough information to > the compiler to make it stop being annoying. I believe you. And I'm not arguing for keeping these kinds of warnings in -Wall. Rather I argue for making them part of a specific "static analysis-like compilation mode". False positives are still (and always will be) problematic. But less so than in -Wall or -Wextra, IMHO. I remember that in some distant past ;-) I had to change something like cond ? foo[n] : 0; to cond ? foo[cond ? n : 0] : 0; I suspect that may be similar to what you had to do? -- ────────────────────────────────────────────────────────────────────────── Dr. Matthias Kretz https://mattkretz.github.io GSI Helmholtz Center for Heavy Ion Research https://gsi.de std::simd ──────────────────────────────────────────────────────────────────────────