https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82047
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82047
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2017-08-31 00:00:00 |2021-8-23
--- Comment #8 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82047
--- Comment #7 from Louis Dionne ---
Then, I think there's another bug in GCC (or maybe just a QOI issue), since the
following code compiles (wandbox[1]):
template constexpr T v;
template constexpr T v(888);
struct S {
constexpr S()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82047
--- Comment #6 from Jonathan Wakely ---
I don't think it does mandate that. I think I was wrong to say (in comment 1)
that it's only a declaration. I believe it's a definition too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82047
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82047
--- Comment #4 from Jonathan Wakely ---
Because std::complex has a default constructor that initializes all its
members. If you replace S with a type that leaves some members uninitialized
when default-initialized, it fails:
template struct S {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82047
--- Comment #3 from John McFarlane ---
This still happens when S has member variables. For example, if `S` is
replaced with `std::complex`, then `v>` is `{0,0}`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82047
--- Comment #2 from Jonathan Wakely ---
Actually I wonder if this is due to GCC implementing a solution for
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#253
The relevant rule is:
"A constexpr specifier used in an object declarati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82047
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
