Re: [C++ Patch] PR 85112 ("[8 Regression] ICE with invalid constexpr")

[Jason Merrill <jason at redhat dot com>]

On Fri, Apr 13, 2018 at 5:05 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>
> in this error-recovery regression, after a sensible error message issued by
> cxx_constant_init, store_init_value stores an error_mark_node as
> DECL_INITIAL of the VAR_DECL for 'j'. This error_mark_node reappears much
> later, to cause a crash during gimplification. As far as I know, the choice
> of storing error_mark_nodes too is the outcome of a rather delicate
> error-recovery strategy and I don't think we want to revisit it at this
> time, thus the remaining option is catching later the error_mark_node, at a
> "good" time. I note, in passing, that the do loop in gimplify_expr which
> uses the crashing STRIP_USELESS_TYPE_CONVERSION seems a bit lacking from the
> error-recovery point of view, because at each iteration it *does* cover for
> error_operand_p (save_expr) but only immediately after the call, when it's
> too late.
>
> All the above said, I believe that at least for the 8.1.0 needs we may want
> to catch the error_mark_node in cp_build_modify_expr, when we are handling
> the assignment 'a.n = j;': convert_for_assignment produces a NOP_EXPR from
> the VAR_DECL for 'j' which then cp_convert_and_check regenerates (deep in
> convert_to_integer_1 via maybe_fold_build1_loc) in the final bare-bone form,
> with the error_mark_node as the first operand. Passes testing on
> x86_64-linux.

We should avoid wrapping an error_mark_node in a NOP_EXPR in the first place.

Jason