This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")
- From: Jason Merrill <jason at redhat dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 8 May 2018 15:24:12 -0400
- Subject: Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")
- References: <a2d7e7d4-06b0-95b3-74bf-b181beabfa2e@oracle.com> <CADzB+2kFk3FzCm6d5sKB=mJrfJ7ZS8PtGoXabvt3UphVvbbDeQ@mail.gmail.com> <18131349-5ccb-d567-3154-fe92c781e696@oracle.com>
On Tue, May 8, 2018 at 1:46 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>
> On 08/05/2018 19:15, Jason Merrill wrote:
>>
>> On Fri, Apr 20, 2018 at 1:46 PM, Paolo Carlini <paolo.carlini@oracle.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> in this error-recovery regression, after sensible diagnostic about "two
>>> or
>>> more data types in declaration..." we get confused, we issue a cryptic -
>>> but useful hint to somebody working on the present bug ;) - "template
>>> definition of non-template" error and we finally crash. I think the issue
>>> here is that we want to use abort_fully_implicit_template as part of the
>>> error recovery done by cp_parser_parameter_declaration_list, when the
>>> loop
>>> is exited early after a cp_parser_parameter_declaration internally called
>>> synthesize_implicit_template_parm. Indeed, if we do that we get the same
>>> error recovery behavior we get for the same testcase modified to not use
>>> an
>>> auto parameter (likewise for related testcases):
>>>
>>> struct a {
>>> void b() {}
>>> void c(auto = [] {
>>> if (a a(int int){})
>>> ;
>>> }) {}
>>> };
>>
>> Hmm, the erroneous declaration is within the lambda body, so messing
>> with whether c is a template seems wrong.
>
> I'm sorry, I don't follow: why you think the issue has to do with c? The
> issue happens while we are parsing:
>
> a a(int auto)
>
> in the original testcase, in particular the parameters. We set
> parser->fully_implicit_function_template_p in
> synthesize_implicit_template_parm, which in turn is called by
> cp_parser_simple_type_specifier when it sees the auto. As I said, we don't
> have the bug for the snippet you quote above, which is identical to that
> attached in the bug but for the auto in the declaration of a:
>
> struct a {
> void b() {}
> void c(void (*) () = [] {
> if (a a(int auto){})
> ;
> }) {}
> };
Ah, I was assuming the quoted testcase was the one in the PR. The patch is OK.
Jason