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: Thu, 21 Dec 2017 11:04:06 -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>
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?
Jason