Re: Is it time to take the middle-end stringop/array warnings out of -Wall?

On Fri, 22 May 2026, 20:00 Matthias Kretz, <[email protected]> wrote:

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


Actually looking again at the latest case, it happens with assertions
disabled. But that's how a lot of optimized code is compiled. If the answer
to these warnings is to always enable libstdc++ assertions, we should start
by enabling them when building GCC itself.



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