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