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
