c++: value-init vs zero-init in expand_aggr_init_1 [PR65816]

In the case of value-initializing an object of class type T,
[dcl.init.general]/8 says:

  - if T has either no default constructor ([class.default.ctor]) or
    a default constructor that is user-provided or deleted, then the
    object is default-initialized;
  - otherwise, the object is zero-initialized and ...  if T has a
    non-trivial default constructor, the object is default-initialized;

But when determining whether to first zero-initialize the object,
expand_aggr_init_1 incorrectly considers the user-providedness of _all_
constructors rather than only that of the _default_ constructors.  This
causes us to skip the zero-initialization step when the class type has a
defaulted default constructor alongside a user-defined constructor.

It seems the predicate type_has_non_user_provided_default_constructor
accurately captures the above rule for when to first perform a
zero-initialization during value-initialization, so this patch adjusts
expand_aggr_init_1 to use this predicate instead.

	PR c++/65816

gcc/cp/ChangeLog:

	* init.c (expand_aggr_init_1): Check
	type_has_non_user_provided_default_constructor instead of
	type_has_user_provided_constructor.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/constexpr-delegating3.C: New test.
	* g++.dg/cpp0x/dc10.C: New test.
	* g++.dg/cpp0x/initlist-base4.C: New test.
	* g++.dg/cpp2a/constexpr-init22.C: New test.

libstdc++-v3/ChangeLog:

	* testsuite/23_containers/deque/allocator/default_init.cc,
	testsuite/23_containers/forward_list/allocator/default_init.cc,
	testsuite/23_containers/list/allocator/default_init.cc,
	testsuite/23_containers/map/allocator/default_init.cc,
	testsuite/23_containers/set/allocator/default_init.cc,
	testsuite/23_containers/vector/allocator/default_init.cc,
	testsuite/23_containers/vector/bool/allocator/default_init.cc:
	Remove xfail.

0 files changed, 0 insertions, 0 deletions