https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93790
--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Marek Polacek <mpola...@gcc.gnu.org>: https://gcc.gnu.org/g:830c572428758f134bd001e699a08e622e2452c3 commit r10-7656-g830c572428758f134bd001e699a08e622e2452c3 Author: Marek Polacek <pola...@redhat.com> Date: Wed Apr 8 17:03:53 2020 -0400 c++: Fix wrong paren-init of aggregates interference [PR93790] This PR points out that we are rejecting valid code in C++20. The problem is that we were surreptitiously transforming T& t(e) into T& t{e} which is wrong, because the type of e had a conversion function to T, while aggregate initialization of t from e doesn't work. Therefore, I was violating a design principle of P0960, which says that any existing meaning of A(b) should not change. So I think we should only attempt to aggregate-initialize if the original expression was ill-formed. Another design principle is that () should work where {} works, so this: struct S { int i; }; const S& s(1); has to keep working. Thus the special handling for paren-lists with one element. (A paren-list with more than one element would give you "error: expression list treated as compound expression in initializer" C++17.) PR c++/93790 * call.c (initialize_reference): If the reference binding failed, maybe try initializing from { }. * decl.c (grok_reference_init): For T& t(e), set LOOKUP_AGGREGATE_PAREN_INIT but don't build up a constructor yet. * g++.dg/cpp2a/paren-init23.C: New test. * g++.dg/init/aggr14.C: New test.
