https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88146
--- Comment #10 from Alexandre Oliva <aoliva at gcc dot gnu.org> --- Author: aoliva Date: Wed Dec 19 06:51:19 2018 New Revision: 267250 URL: https://gcc.gnu.org/viewcvs?rev=267250&root=gcc&view=rev Log: [PR c++/88146] do not crash synthesizing inherited ctor(...) This patch started out from the testcase in PR88146, that attempted to synthesize an inherited ctor without any args before a varargs ellipsis and crashed while at that, because of the unguarded dereferencing of the parm type list, that usually contains a terminator. The terminator is not there for varargs functions, however, and without any other args, we ended up dereferencing a NULL pointer. Oops. Guarding accesses to parm would be easy, but not necessary. In do_build_copy_constructor, non-inherited ctors are copy-ctors, that always have at least one parm, so parm needs not be guarded when we know the access will only take place when we're dealing with an inherited ctor. The only other problematic use was in the cvquals initializer, a variable only used in a loop over fields, that we skipped individually in inherited ctors. I've guarded the cvquals initialization and the entire loop over fields so they only run for copy-ctors. Avoiding the crash from unguarded accesses was easy, but I thought we should still produce the sorry message we got in other testcases that passed arguments through the ellipsis in inherited ctors. I put a check in, and noticed the inherited ctors were synthesized with the location assigned to the class name, although they were initially assigned the location of the using declaration. I decided the latter was better, and arranged for the better location to be retained. Further investigation revealed the lack of a sorry message had to do with the call being in a non-evaluated context, in this case, a noexcept expression. The sorry would be correctly reported in other contexts, so I rolled back the check I'd added, but retained the source location improvement. I was still concerned about issuing sorry messages while instantiating template ctors even in non-evaluated contexts, e.g., if a template ctor had a base initializer that used an inherited ctor with enough arguments that they'd go through an ellipsis. I wanted to defer the instantiation of such template ctors, but that would have been wrong for constexpr template ctors, and already done for non-constexpr ones. So, I just consolidated multiple test variants into a single testcase that explores and explains various of the possibilities I thought of. for gcc/cp/ChangeLog PR c++/88146 * method.c (do_build_copy_constructor): Guard cvquals init and loop over fields to run for non-inherited ctors only. (synthesize_method): Retain location of inherited ctor. for gcc/testsuite/ChangeLog PR c++/88146 * g++.dg/cpp0x/inh-ctor32.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor32.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog
