This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ Patch] PR 85014 ("[7/8/9 Regression] internal compiler error: in lookup_base, at cp/search.c:185")
- 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: Fri, 15 Mar 2019 13:42:37 -0400
- Subject: Re: [C++ Patch] PR 85014 ("[7/8/9 Regression] internal compiler error: in lookup_base, at cp/search.c:185")
- References: <07a88118-55bf-a1e0-08d0-9d7f0bef2fbf@oracle.com>
On 3/15/19 9:28 AM, Paolo Carlini wrote:
Hi,
another - rather long standing - error-recovery regression, where, in
some rather special circumstances, we end up passing the FUNCTION_DECL
representing the operator () of the lambda to maybe_dummy_object and
obviously we almost immediately crash. Not sure how much we want to dig
- but simply checking that context_for_name_lookup is actually returning
a type appears to work fine, the error_mark_node then propagates back to
cp_parser_late_parse_one_default_arg and so on. In the special
circumstances of the testcase, context_for_name_lookup finds
ANON_AGGR_TYPE_P set for the DECL_CONTEXT of 'b' and iterates to its
TYPE_CONTEXT which is the FUNCTION_DECL representing the operator () of
the lambda. This is because we just called check_tag_decl on that
anonymous type as part of calling shadow_tag on the abstract
declaration. Tested x86_64-linux.
OK.
Jason