[RFC] Builtins for C++26 integer atomic reductions

[Soumya AR]

Ping. (Also summarizing some relevant discussions on IRC)

We don't think these can be implemented using pattern-matching, as fetch_ops or
CAS loops produce visible reads, while reductions do not.

Therefore, pattern-matching an unused fetch_op result into a reduction would
remove the visible read, which could violate memory orderings.

Even if the fetch_op is in RELAXED memory ordering, fences can still synchronize
on that visible read, as is seen in the Litmus test from Will Deacon in
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3111r8.html.

Given these constraints, and knowing the best possible approach is ideally
one that uses the least builtins, is it OK to implement this using Option 1? 

Thanks,
Soumya

> On 24 Feb 2026, at 11:57 AM, Soumya AR <soumyaa@nvidia.com> wrote:
> 
> Hi,
> 
> I'm working on implementing support for C++26 atomic reductions in GCC.
> 
> Corresponding paper for this:
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3111r8.html
> 
> I'd like to get some insight into the preferable builtin interface. As I see it,
> we have the following options: 
> 
> Option 1 (that we expect to implement): One generic builtin per new operation
> 
> We add the generic builtin for each new operation and resolve it in the
> middle-end later. This is similar to the atomic int fetch_min/max implementation
> in this patch:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2026-January/706242.html
> 
> This would result in 7 new builtins, 1 for each new operation.
> 
> Option 2: Explicit builtins per operation and their types:
> 
> This would follow the existing pattern and add a new family of builtins.
> Assuming we name them __atomic_store_<op>, we would have:
> __atomic_store_add,
> __atomic_store_sub,
> __atomic_store_and,
> __atomic_store_or,
> __atomic_store_xor,
> __atomic_store_max,
> __atomic_store_min,
> and all of their typed variants (_N, _1, _2, _4, _8, _16), resulting in 42 new
> builtins.
> 
> However, this would again result in the earlier issue of a builtin explosion
> wrt integer fetch min/max discussed here: 
> https://gcc.gnu.org/pipermail/gcc-patches/2025-November/699602.html
> 
> Option 3: Extend existing __atomic_fetch_* builtins
> 
> Add a parameter to the existing __atomic_fetch_* builtins to choose their
> no-read / reduction variant.
> 
> Although this leads to no new builtins added, the name fetch_* would become a
> misnomer for these and lead to a confusing user interface.
> 
> Would appreciate some feedback on what would be the best step forward here for
> GCC. Will accordingly get feedback from the LLVM community on this as well.
> 
> Best,
> Soumya
>