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
