This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ Patch] PR 81055 ("[6/7/8 Regression] ICE with invalid initializer for array new")
- 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: Wed, 10 Jan 2018 10:06:03 -0500
- Subject: Re: [C++ Patch] PR 81055 ("[6/7/8 Regression] ICE with invalid initializer for array new")
- Authentication-results: sourceware.org; auth=none
- References: <483ea99f-0d5c-2726-b5ed-1525a7919f35@oracle.com> <CADzB+2=3Y64RA_3=+8TUf+riP0+BEaHCn76NEyO_Q3wRJsmivw@mail.gmail.com> <d62e2919-617a-0f77-9c19-7cb5dc974b83@oracle.com>
OK.
On Thu, Dec 21, 2017 at 2:21 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>
> On 21/12/2017 17:04, Jason Merrill wrote:
>>
>> On Wed, Dec 20, 2017 at 10:37 AM, Paolo Carlini
>> <paolo.carlini@oracle.com> wrote:
>>>
>>> in this error recovery regression, after a sensible error produced by
>>> unqualified_name_lookup_error we ICE much later when gimplify_modify_expr
>>> encounters a corresponding error_mark_node as second argument of a
>>> MODIFY_EXPR. I believe we have a very general error recovery weakness
>>> with
>>> errors like unqualified_name_lookup_error and functions like
>>> cp_parser_initializer_list returning a vec: certainly we don't want to
>>> give
>>> up the parsing too early but then we have to cope with error_mark_nodes
>>> filtering down and reappearing much later in the compilation. The present
>>> bug is a rather clear example, but I have seen many others in the past: a
>>> couple of times I even tried doing something about it, but I have yet to
>>> figure out something worth sending to the mailing list. Anyway, here I'm
>>> wondering if at this stage it would make sense to handle the
>>> error_mark_node
>>> in gimplify_modify_expr - I believe we do have a couple other cases of
>>> such
>>> late handling in the gimplifier. Tested x86_64-linux.
>>
>> This seems fine, but the front end shouldn't have created such a
>> MODIFY_EXPR in the first place. How does this happen?
>
> Thanks for asking: a good cure for my laziness ;)
>
> In fact, it's an INIT_EXPR, created by build_vec_init around line #4402. The
> below works for the testcase and I'm finishing regtesting it. Alternately,
> only setting errors = true when init == error_mark_node, which eventually
> leads anyway to build_vec_init returning error_mark_node, also works for the
> testcase: it's a little lighter, so to speak, but less explicit (setting
> elt_init = error_mark_node leads to errors = true too a few lines below).
>
> Thanks!
> Paolo.
>
> ////////////////////////