Re: [PATCH 3/5] compiler_attributes: Add overflow_behavior macros __ob_trap and __ob_wrap

[Justin Stitt <justinstitt@google.com>]

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