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]>
Jason Merrill via Gcc [Thursday, 21 May 2026, 20:12:01 CEST]:
> > 3) add diagnostic group -Wmiddle-end (name pending);
> 
> 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".

Consider:

  char str[] = "Hello";

  // precondition: cond == false
  char
  f(bool cond)
  { return cond ? str[100] : str[0]; }

This warns about str[100] being out of bounds. But the real problem was that f 
was called out-of-contract. If we add "pre (cond == false)" and compile with 
-fno-contracts-conservative-ipa (and a terminating contracts evaluation 
semantic) the warning goes away.

So you can think about these warnings as "your function is missing a 
precondition check". Conceptually. Because C++ contracts currently default to 
hiding from the optimizer.

Thus:
1. middle-end warnings should hint at missing precondition checks
2. middle-end warnings maybe should only be on by default if contracts 
checking is visibly (to the optimizer) terminating. (I've been using 
__builtin_trap for this.)

On the name: "-Wmiddle-end" is an explanation to compiler devs and nobody 
else. How about something in the direction of "-Wstatic-precondition-
checking"?

- Matthias

> let's focus on the most common problems,
> namely the ones supported by -fdiagnostics-show-context=N.  Maybe
> -Wrange-flow or something like that?
> 
> I also notice that pass_warn_access (-Wstringop-overflow) runs multiple
> times in passes.def; maybe the early run could stay in -Wall?  Maybe even
> adjust all of the offending warnings to run before jump threading in -Wall
> and also optionally later?


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