https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:99dd1be14172445795f0012b935359e7014a2215
commit r15-502-g99dd1be14172445795f0012b935359e7014a2215
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #6 from Jonathan Wakely ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #5 from Jonathan Wakely ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #4 from Andrew Pinski ---
Hmm, Does this matter that much since HLE has been disabled on all cores?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #3 from Jonathan Wakely ---
No, it's just a different, but still conforming, interpretation of the
standard.
> For an enumeration whose underlying type is not fixed, the underlying type
> is an integral type that can represent all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #2 from Richard Biener ---
Why do we care for -fshort-enums? Aren't those outside of the standard?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
