public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums
[not found] <bug-89624-4@http.gcc.gnu.org/bugzilla/>
@ 2024-04-09 3:26 ` pinskia at gcc dot gnu.org
2024-04-11 11:10 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-09 3:26 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums
[not found] <bug-89624-4@http.gcc.gnu.org/bugzilla/>
2024-04-09 3:26 ` [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
@ 2024-04-11 11:10 ` redi at gcc dot gnu.org
2024-04-11 11:13 ` redi at gcc dot gnu.org
2024-05-15 9:19 ` cvs-commit at gcc dot gnu.org
3 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2024-04-11 11:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums
[not found] <bug-89624-4@http.gcc.gnu.org/bugzilla/>
2024-04-09 3:26 ` [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
2024-04-11 11:10 ` redi at gcc dot gnu.org
@ 2024-04-11 11:13 ` redi at gcc dot gnu.org
2024-05-15 9:19 ` cvs-commit at gcc dot gnu.org
3 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2024-04-11 11:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums
[not found] <bug-89624-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2024-04-11 11:13 ` redi at gcc dot gnu.org
@ 2024-05-15 9:19 ` cvs-commit at gcc dot gnu.org
3 siblings, 0 replies; 4+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-15 9:19 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-05-15 9:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-89624-4@http.gcc.gnu.org/bugzilla/>
2024-04-09 3:26 ` [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
2024-04-11 11:10 ` redi at gcc dot gnu.org
2024-04-11 11:13 ` redi at gcc dot gnu.org
2024-05-15 9:19 ` cvs-commit at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).