> Am 22.05.2026 um 13:49 schrieb Matthias Kretz <[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"?
I think this is a good observation. Much like that diagnostics that do this
should probably enable diagnostic-paths, at least for their emitted
diagnostics. Because the path is what shows the currently visible
preconditions. Remember that esp. with C++ the set of visible preconditions is
heavily dependent on inlining decisions.
Richard
>
> - 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
> ──────────────────────────────────────────────────────────────────────────
