On Wed, Dec 20, 2017 at 10:37 AM, Paolo Carlini <paolo.carl...@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
