https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940
Andrew Pinski changed:
What|Removed |Added
CC||klaus.doldinger64@googlemai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940
Andrew Pinski changed:
What|Removed |Added
CC||marc.mutz at hotmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.4
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/bugzilla/show_bug.cgi?id=78940
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Known to work|
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
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
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
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
