Re: [PATCH 3/5] compiler_attributes: Add overflow_behavior macros __ob_trap and __ob_wrap
From: Justin Stitt
Date: Tue Sep 08 2026 - 18:41:56 EST
Hi,
On Wed, Apr 01, 2026 at 11:20:27AM +0200, Peter Zijlstra wrote:
...
>
> So I would like to second this option as being interesting.
>
> But while pondering it, I did want to note that all of the options, with
> the exception of __ob_wrap (which is effectively what we have today for
> *everything*), will be 'interesting' to compose with _Atomic, another
> one of these qualifiers.
>
> Now, in the kernel we don't use _Atomic, so strictly speaking I don't
> care ;-) But here goes...
>
> Something like _Atomic int __ob_wrap, is trivial and good.
>
> _Atomic int __ob_trap is either doable or impossible depending on how
> you define the result to be on 'trap'. Specifically, the semantics
> proposed where it keeps the old value makes it impossible.
>
> And _Atomic int __ob_saturate is equally 'challenging', since the
> fundamental thing of 'reset to min/max on under/over-flow' is rather
> a non-atomic kind of thing. Look at the trouble we went through with
> refcount_t to sort of make this work.
>
FWIW, I've moved to simply disallow OBT+Atomic. We've got this under
-fexperimental so I'm well within my right :). The idea being: __ob_trap
isn't workable with Atomic (depending on storage semantics) and
__ob_wrap isn't very useful there either, plus I had some parsing bugs
where specific ordering of things could result in OBT being silently
dropped with _Atomic and those magically go away by disallowing this
pairing all together.
I just opened the PR over at [1] and it is still pending but this is
probably where I'll go with _Atomic and OBT :)
Link: https://github.com/llvm/llvm-project/pull/222179
Thanks
Justin