diff options
author | Jonathan Wakely <jwakely@redhat.com> | 2024-04-11 19:12:48 +0100 |
---|---|---|
committer | Jonathan Wakely <jwakely@redhat.com> | 2024-05-15 10:18:14 +0100 |
commit | 99dd1be14172445795f0012b935359e7014a2215 (patch) | |
tree | 3f8b6c596ca70dfb775f80fc512e20ef14769aa6 /gcc | |
parent | 642f31d6286b8a342130fbface51530befd975fd (diff) | |
download | gcc-99dd1be14172445795f0012b935359e7014a2215.zip gcc-99dd1be14172445795f0012b935359e7014a2215.tar.gz gcc-99dd1be14172445795f0012b935359e7014a2215.tar.bz2 |
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.
Diffstat (limited to 'gcc')
0 files changed, 0 insertions, 0 deletions