This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ Patch] PR 84605 ("[7/8/9 Regression] internal compiler error: in xref_basetypes, at cp/decl.c:13818")
- From: Jason Merrill <jason at redhat dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 4 Mar 2019 11:58:21 -0500
- Subject: Re: [C++ Patch] PR 84605 ("[7/8/9 Regression] internal compiler error: in xref_basetypes, at cp/decl.c:13818")
- References: <9fae7281-9921-1a49-01f3-2bb8690b3577@oracle.com>
On 3/4/19 6:03 AM, Paolo Carlini wrote:
Hi,
this error recovery regression too is rather easy to explain: since
Jason's fix for c++/79580 (r245587) when defining a type from within an
expression we pass ts_within_enclosing_non_class to xref_tag when we
call it from cp_parser_class_head. Thus, in the ill-formed testcases at
issue, cp_parser_class_head is called twice for the same 'type' returned
by xref_tag, and the second time TYPE_BINFO is already set while
TYPE_SIZE is still zero, thus the gcc_assert in xref_basetypes triggers.
A rather straightforward way to give again an error message instead of
crashing is rejecting TYPE_BEING_DEFINED too, additionally to
COMPLETE_TYPE_P. in the check placed between the xref_tag and the
xref_basetypes calls. The wording of the error message is probably a tad
suboptimal in the TYPE_BEING_DEFINED case, but I'm not sure it's worth
spending time and code on that, the issue appears anyway to be rather
rare and all the testcases I have are error-recovery ones. Tested
x86_64-linux.
OK.
Jason