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
──────────────────────────────────────────────────────────────────────────
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.