On Mon, 5 Jan 2026 at 14:09, Jonathan Wakely <[email protected]> wrote: > > On Fri, 5 Dec 2025 at 09:17, Soumya AR <[email protected]> wrote: > > > > Hi Jonathan, > > > > Pinging again for some clarification on what is the ideal way to implement > > atomic min/max in libstdc++. > > Sorry, I missed that there were questions for libstdc++ that are > independent of the compiler built-ins discussion. > > Responses below ... > > > > > Would you prefer we check for the builtins using concepts (similar to fp > > add/sub)? If so, the earlier questions in this thread still apply. > > > > If not, since I do have a patch that implements the builtins in GCC, would > > you > > prefer the builtins be called directly, without a concept check? > > > > Patch is at: > > https://gcc.gnu.org/pipermail/gcc-patches/2025-November/700786.html > > > > Please let me know if the general approach for this is OK. > > > > Thanks, > > Soumya > > > > > > > > On 11 Nov 2025, at 4:31 PM, Soumya AR <[email protected]> wrote: > > > > Hi Jakub and Jonathan, > > > > Pinging on this again to ask for confirmation. > > > > As Matthew mentioned earlier, does it sound OK to have patches in this > > order: > > > > - Have builtins used in libstdc++ (under SFINAE checks). > > - Have builtins defined and emitting correct code for AArch64. > > - Add the CAS pattern matching into an IFN. > > > > > > We'd like to continue with the 2nd option that Jakub suggested — lowering > > the > > generic builtin to an IFN, and converting that to a CAS loop after IPA if > > the backend does not support a direct optab. > > > > --- > > > > As for changes on the libstdc++ side, since we cannot emit a direct call to > > the > > builtins and need to resolve these appropriately under SFINAE, how do we > > handle > > implemnting the SFINAE check for __atomic_base? > > > > I would like to ideally emit less calls to the compiler builtins and thus > > have > > a single check for the builtin, the way it is currently implemented in > > __atomic_impl. > > > > What would be a neater way to tackle this? > > > > - Forward declaration of just the min/max functions from __atomic_impl and > > resolve them using the __atomic_impl implementation for __atomic_base > > Yes please. > > > - Move the SFINAE checks outside __atomic_impl. This messes with the current > > philosophy of __atomic_impl though, as I understand it > > - Resolve the integer types using a separate SFINAE check. Would result in > > code > > duplication though > > - Any other suggestion I'm missing? > > > > Lastly, how do we guard these for C++26? > > That one is easy: > > #if __cplusplus >= 202400L
Actually no, there's a feature test macro added by P0493R4: #define __cpp_lib_atomic_min_max 202403L That should be defined in bits/version.def
