There is a bit of discussion on gcc here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112

On Fri, Mar 27, 2026 at 5:11 PM Adrian Johnston <ajohnston4536_at_[hidden]>
wrote:

>
> I am not sure what the hold up with gcc is. They have an idiom for it.
> This works:
>
>
>
>
>
>
>
>
>
>
>
>
> *#define ASSUME(x) do { if (!(x)) __builtin_unreachable(); } while
> (0)struct S { bool b;};void callit();void func(S s) { ASSUME(s.b);
> if (!s.b) callit();}*
>
> This indicates they have the machinery in place. However, as I noted in a
> separate message, it will call functions inside x, making it difficult to
> use globally. It looks like this is just a matter of priorities, rather
> than a fundamental issue.
>
> I was just reading the steering groups paper:
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p2000r5.pdf
>
> And safety is a major focus coming from them. So I would love to see P2900
> style assertions put into the standard library instead of having UB
> everywhere. That would also allow an evaluation semantics mode "assume" as
> I described previously to leverage those assertions where it was deemed
> safe to do so.
>
> Anyway, it looks like this might even be a post-C++29 thing to talk about
> as P2900 is just getting ratified and only has experimental support... I
> will try and come up with a better benchmark.
>
>
>
>
> On Fri, Mar 27, 2026 at 2:10 AM Ivan Lazaric via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> > I am not against assume semantic, but will note (some) compilers are not
> super strong on using the information from [[assume(...)]] attribute at the
> moment
> >
> > struct S {
> > bool b;
> > };
> >
> > void callit();
> >
> > void func(S s) {
> > [[assume(s.b)]];
> > if (!s.b) callit();
> > }
> >
> > One would hope func() would be reduced to just a ret instruction, but
> with gcc we get:
> >
> > "func(S)":
> > test dil, dil
> > je .L4
> > ret
> > .L4:
> > jmp "callit()"
> >
> > Godbolt of this: https://godbolt.org/z/3bb1fx6E9
> > Clang does optimize it out though: https://godbolt.org/z/sqMMrzh4W
> >
> >
> > On Fri, Mar 27, 2026 at 9:57 AM Peter Bindels via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >>
> >> P2900 is focused on (functional) safety first and foremost. Any assume
> semantic does not make sense, and adding that to the discussion will muddle
> the story on what contracts bring first and foremost.
> >>
> >> That said, the concept of an assume semantic is well-understood, and
> many are indeed asking for it. I suspect that compilers will be
> implementing it even if the C++ standard does not mention it, and users
> will be trying it out, and finding that for correct invocations it indeed
> works the same (modulo compiler bugs), while for buggy calls it can have
> terrifying optimizations applied based on them not happening.
> >>
> >> It is probably a good idea to write a paper to propose specifically
> only the assume semantic, and to defend that in WG21 with lots of actual
> performance data from a code base that uses P2900/C++26 contracts
> extensively, to show what its impact is and why that should warrant being
> standardized. You will likely get a big discussion on safety, but for
> "release builds" as colloquially known they should be effectively what we
> have done before.
> >>
> >> On Fri, Mar 27, 2026 at 5:29 AM Adrian Johnston via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >>>
> >>> We have P2900 in the works and it is moving us away from the "roll
> >>> your own" situation we have been in with respect to asserts for the
> >>> last 37 years. So ergonomics is part of it.
> >>>
> >>> And as far as I know, P2900 specifies an evaluation semantics mode
> >>> without defining how a macro would be defined in terms of the current
> >>> evaluation semantics mode. That is one barrier. The other issue is
> >>> that the [[assume]] attribute prohibits function calls which is an
> >>> issue with global blanket use. (clang has -Wno-assume for function
> >>> calls in __builtin_assume, gcc had no satisfactory solution for that
> >>> in my tests.)
> >>>
> >>> Lastly, I think the proposal I am trying to float here encourages more
> >>> safety around the use of "assume" semantics. This is because it
> >>> provides a way to check your assumptions in a debug build. And safety
> >>> is all the rage these days.
> >>>
> >>>
> >>> On Thu, Mar 26, 2026 at 8:22 PM JJ Marr <jjmarr_at_[hidden]> wrote:
> >>> >
> >>> > I'm a big fan of the idea. Why isn't a macro of an assertion
> followed by an assumption sufficient?
> >>> >
> >>> > On Thu, Mar 26, 2026, 5:41 p.m. Adrian Johnston via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >>> >>
> >>> >> Hello,
> >>> >>
> >>> >> I would like to propose [[assume_assert(expr)]] which would be a
> >>> >> hybrid of contract_assert and [[assert(expr)]] that selects between
> >>> >> the behavior of the two depending on the evaluation semantics mode
> as
> >>> >> described in P2900:
> >>> >>
> >>> >> - ignore: same as [[assume(expr)]]
> >>> >> - observe: same as contract_assert(expr)
> >>> >> - enforce: same as contract_assert(expr)
> >>> >> - quick-enforce: same as contract_assert(expr)
> >>> >>
> >>> >> These have the benefit of alerting the developer in a debug build
> when
> >>> >> [[assume(expr)]] has been misused and hopefully reduce the amount of
> >>> >> undefined behavior associated with the use of [[assume(expr)]].
> >>> >>
> >>> >> As an alternative to this approach, an evaluation semantics mode
> >>> >> "assume" could be added which would convert all P2900 contract
> >>> >> assertions to have [[assume(expr)]] semantics.
> >>> >>
> >>> >> proposed evaluation semantics:
> >>> >> - ignore: unchanged
> >>> >> - observe: unchanged
> >>> >> - enforce: unchanged
> >>> >> - quick-enforce: unchanged
> >>> >> - assume: replace pre(expr), post(expr), post(ret, expr),
> >>> >> contract_assert(expr) with [[assume(expr)]] semantics.
> >>> >>
> >>> >> The one major issue here is that the current standard says an assume
> >>> >> statement cannot call functions, and this limitation would not be
> >>> >> enforceable across a non-trivial application. Instead, I would
> propose
> >>> >> that function calls would result in the expression being ignored
> when
> >>> >> evaluation semantics are set to mode "assume". In this case a
> warning
> >>> >> would not be recommended as that would break strict builds.
> >>> >>
> >>> >> I have implemented this kind of [[assume_assert(expr)]] using
> >>> >> compiler-specific intrinsics and used it for every last assertion
> in a
> >>> >> non-trivial codebase. It worked great, and so I am recommending it
> for
> >>> >> the next version of C++26.
> >>> >>
> >>> >> I would also like to suggest things like assume_pre (expr) and
> >>> >> assume_post (expr) although that pollutes the global namespace for a
> >>> >> feature that is less commonly used.
> >>> >>
> >>> >> My recommendation would be to add [[assume_assert(expr)]] and
> >>> >> evaluation semantics mode "assume".
> >>> >>
> >>> >> Regards,
> >>> >> Adrian
> >>> >> --
> >>> >> Std-Proposals mailing list
> >>> >> Std-Proposals_at_[hidden]
> >>> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> >>> --
> >>> Std-Proposals mailing list
> >>> Std-Proposals_at_[hidden]
> >>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> >>
> >> --
> >> Std-Proposals mailing list
> >> Std-Proposals_at_[hidden]
> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>