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

Richard Biener via Gcc [Saturday, 23 May 2026, 12:56:20 CEST]:
> That's how -Warray-bounds works, it warns only if all possible values
> (according to range) are not valid.

Good. That was my assumption from the start.

> One issue with "reachable" is that this is all conditional on a function
> being entered at all (which we basically assume when deciding between may
> and must).  So how a diagnostic is framed to the user can depend on
> inlining (inlining a function into conditional context turns a must into a
> may diagnostic).

👍

The simple part:

If a function is not declared inline, then it is only correct to assume the 
function will be called with all possible inputs. The range of inputs can only 
be reduced via preconditions (either via termination or assumption). In such a 
function, a not-eliminated branch that leads to UB implies a precondition that 
equals the conditions guarding the UB. I guess, in theory this could be used 
to define implicit precondition expressions for functions. But I think more 
useful is an optional diagnostic about missing precondition checks. As long as 
this is just part of the optimizer's work, such a diagnostic must be 
conditional on whether precondition checks are terminating/assuming.

The hard part (aka IPA should do more):
https://compiler-explorer.com/z/s9zT6nsMY

char str[10] = {};

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

[[gnu::noinline]] // without this the warning goes away
inline void
assume_from_this(int x)
{
  if (x >= 0)
    __builtin_trap();
}

// precondition: x < 0
char
g(int x)
{
  assume_from_this(x);
  return f(x > 0);
}

Here is an example of an inline function that doesn't get inlined. When that 
happens (and it can happen through seemingly unrelated code changes), then 
suddenly the warning appears. When `assume_from_this` is inlined the 
`str[100]` branch is dead code. When it's not inlined, IMHO IPA should still 
extract the assumption the trap implies into the calling function. I would 
hope that thus the heuristics of inlining stop affecting the outcome of 
middle-end warnings. I'm surely missing more cases, but that would at least 
eliminate one case.

-- 
──────────────────────────────────────────────────────────────────────────
 Dr. Matthias Kretz                           https://mattkretz.github.io
 GSI Helmholtz Center for Heavy Ion Research               https://gsi.de
 std::simd
──────────────────────────────────────────────────────────────────────────