[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #7 from Pablo Anigstein ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Jonathan Wakely from comment #3)
> > (In reply to Pablo Anigstein from comment #2)
> > > (In reply to Andrew Pinski from comment #1)
> > > > Hmm,
> > > > I noticed that since GCC 7 with -std=c++17, the b.x is not initialized
> > > > at
> > > > all. So the question I have is there a difference between C++ standards
> > > > here?
> >
> > Derived is an aggregate in C++17, so b{} does aggregate init, not value
> > init.
>
> And that means its Base subobject is copy-initialized from {} which means we
> get a value-initialized object, so it's correct that b.x is not initialized
> in C++17 (which is what is shown in your godbolt link, because you didn't
> specify any -std option to override the -std=gnu++17 default).
>
> With -std=c++14 it looks like b.x is always set to zero, if I'm reading the
> assembly output correctly (but I'm probably not).
Here is an updated example: https://godbolt.org/z/YePjhxKE4. Note that now
Derived is not an aggregate for any standard version due to the private member.
Still zero-initialization does not happen for the Base sub-object for the case
where Base has a user-provided default constructor when compiling with -O1 and
above.
[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #6 from Pablo Anigstein ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Pablo Anigstein from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Hmm,
> > > I noticed that since GCC 7 with -std=c++17, the b.x is not initialized at
> > > all. So the question I have is there a difference between C++ standards
> > > here?
>
> Derived is an aggregate in C++17, so b{} does aggregate init, not value init.
>
> > > Note the issue is we call Base's constructor after doing the zero
> > > initialization and the Base's constructor has a clobber in it which I
> > > think
> > > is correct.
>
> Maybe we should only clobber in the complete object constructor _ZN4BaseC1Ev
> and not in _ZN4BaseC2Ev.
>
> > > This is all front-end generation and not exactly related to the
> > > optimizations directly.
> >
> > There is no difference between C++ standards in this respect.
>
> Before C++11 there was no zero-init at all. Since C++11 the spec keeps
> changing, but the effects of zero-init are substantially the same. But
> Derived is an aggregate since C++17.
Thank you for the correction. I still think there is non-conformance for all
standards including C++17, I will post a modified example in a comment below.
>
> Aside: What does the comment "not a default constructor" mean in the
> testcase?
I guess he meant "user-provided".
[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993 panigstein at hotmail dot com changed: What|Removed |Added CC||panigstein at hotmail dot com --- Comment #2 from panigstein at hotmail dot com --- (In reply to Andrew Pinski from comment #1) > Hmm, > I noticed that since GCC 7 with -std=c++17, the b.x is not initialized at > all. So the question I have is there a difference between C++ standards here? > > Note the issue is we call Base's constructor after doing the zero > initialization and the Base's constructor has a clobber in it which I think > is correct. > > This is all front-end generation and not exactly related to the > optimizations directly. There is no difference between C++ standards in this respect. For a class that has a defaulted default constructor (Derived), value-initialization consists of zero-initialization followed by default-initialization. The clobbering of the Base sub-object is incorrect here and makes the implementation of value-initialization non-conforming.
