[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 Andrew Pinski changed: What|Removed |Added CC||klaus.doldinger64@googlemai ||l.com --- Comment #7 from Andrew Pinski --- *** Bug 83730 has been marked as a duplicate of this bug. ***
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 Andrew Pinski changed: What|Removed |Added CC||marc.mutz at hotmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 79561 has been marked as a duplicate of this bug. ***
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.4
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104142 Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed in GCC 10.4.0 by the patch which fixed PR 104142.
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Known to work||10.4.0, 10.5.0, 11.4.0, ||12.1.0
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 --- Comment #4 from Avi Kivity --- Since constexpr constructors do send the variable into the .data (or .tls) section, perhaps gcc can attempt to evaluate the initializer as if it (and any functions it calls) was marked constexpr. If it fails it can emit the guard and initialization calls, but if it succeeds, we save some runtime to check those guards.
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 Marc Mutz changed: What|Removed |Added CC||marc.mutz at kdab dot com --- Comment #3 from Marc Mutz --- This is not restricted to thread_locals. It also affects statics in functions: PR 79561
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 --- Comment #2 from Jonathan Wakely --- (In reply to Nadav Har'El from comment #1) > I don't know why the standard decided that the default constructor should > not be marked "constexpr", unlike the value-taking constructors. Because the standard requires that the default constructor doesn't initialize the value, for compatibility with "atomic_int i;" in C which leaves it uninitialized. A constexpr constructor must not leave data uninitialized, so they can't be constexpr if they're C-compatible.
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 --- Comment #1 from Nadav Har'El --- Technically speaking, std::atomic's default constructor is not marked "constexpr" (unlike the value-taking constructor), so I'm guessing that at the time that gcc makes the decision to have these guards, it doesn't yet know that this type will not need a constructor. I don't know why the standard decided that the default constructor should not be marked "constexpr", unlike the value-taking constructors.
