[Bug c++/97128] New: Uninitialized members of base class wrongly allowed in constexpr constructor

2020-09-20 Thread feodor.alexeev+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97128

Bug ID: 97128
   Summary: Uninitialized members of base class wrongly allowed in
constexpr constructor
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: feodor.alexeev+gcc at gmail dot com
  Target Milestone: ---

Given this code: (https://godbolt.org/z/qsaeM7)

struct Base {
int x;
};

struct Derived : Base {
constexpr Derived() { }
};

int main () {
constexpr Derived kDerived;
return kDerived.x;
}

g++ -std=c++17 -pedantic compiles the program that exits with code 0.
clang rejects it as I believe in c++17 for a constructor to be constexpr all
members must be initialized before execution enters the body of the
constructor.

I also believe that the program is invalid as of c++20 as all must be
initialized by the end of the constexpr constructor. Still g++ -std=c++2a
compiles it.

Note that if there was an uninitialized member of Derived itself, g++ would
generate an error as expected.

There is a similar bug filed where g++ wrongly allows uninitialized member of
anonymous struct inside a union member:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86581 . Not sure if this counts as
a duplicate.

[Bug c++/97128] Uninitialized members of base class wrongly allowed in constexpr constructor

2020-09-20 Thread feodor.alexeev+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97128

--- Comment #1 from Fedor Alekseev  ---
Sorry, the link in the initial comment led to a slightly less minimal example.
Here's a link to the code from the initial comment in CE:
https://godbolt.org/z/dWP1sh

[Bug c++/97128] Uninitialized members of base class wrongly allowed in constexpr constructor in c++17 mode

2020-09-20 Thread feodor.alexeev+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97128

--- Comment #2 from Fedor Alekseev  ---
Also my initial claim about c++20 was wrong, gcc 10+ generates the error when
provided with -std=c++2a switch.
Still there is a problem in c++17 mode.