[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums

[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Hmm, Does this matter that much since HLE has been disabled on all cores?

[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think we should just do this:

--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -77,7 +77,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   inline constexpr memory_order memory_order_acq_rel = memory_order::acq_rel;
   inline constexpr memory_order memory_order_seq_cst = memory_order::seq_cst;
 #else
-  typedef enum memory_order
+  enum memory_order : int
     {
       memory_order_relaxed,
       memory_order_consume,
@@ -85,7 +85,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
       memory_order_release,
       memory_order_acq_rel,
       memory_order_seq_cst
-    } memory_order;
+    };
 #endif

   /// @cond undocumented


That ensures a consistent underlying type for C++17 down and C++20 up (and gets
rid of the redundant typedef). This will mean the type isn't affected by the
-fshort-enums flag at all, which also happens to solve the static_assert
failure in comment 0.

This is an ABI change for the underlying type when using -fshort-enums, but
that flag is already explicitly ABI-changing and not the default, so I care
less about a change there.

[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It's also a mostly-harmless ABI change for C++17 down, because the underlying
type without -fshort-enums changes from implicitly being chosen as unsigned
int, to explicitly being specified as int.

[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:99dd1be14172445795f0012b935359e7014a2215

commit r15-502-g99dd1be14172445795f0012b935359e7014a2215
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Apr 11 19:12:48 2024 +0100

    libstdc++: Give std::memory_order a fixed underlying type [PR89624]

    Prior to C++20 this enum type doesn't have a fixed underlying type,
    which means it can be modified by -fshort-enums, which then means the
    HLE bits are outside the range of valid values for the type.

    As it has a fixed type of int in C++20 and later, do the same for
    earlier standards too. This is technically a change for C++17 down,
    because the implicit underlying type (without -fshort-enums) was
    unsigned before. I doubt it matters in practice. That incompatibility
    already exists between C++17 and C++20 and nobody has noticed or
    complained. Now at least the underlying type will be int for all -std
    modes.

    libstdc++-v3/ChangeLog:

            PR libstdc++/89624
            * include/bits/atomic_base.h (memory_order): Use int as
            underlying type.
            * testsuite/29_atomics/atomic/89624.cc: New test.