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.
(cherry picked from commit
99dd1be14172445795f0012b935359e7014a2215)
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,
memory_order_release,
memory_order_acq_rel,
memory_order_seq_cst
- } memory_order;
+ };
#endif
/// @cond undocumented
--- /dev/null
+// { dg-options "-fshort-enums" }
+// { dg-do compile { target c++11 } }
+
+// Bug 89624 HLE bits don't work with -fshort-enums or -fstrict-enums
+
+#include <atomic>
+
+static_assert((std::memory_order_acquire | std::__memory_order_hle_acquire)
+ != std::memory_order_acquire, "HLE acquire sets a bit");