On Fri, Apr 13, 2018 at 1:18 PM, Paolo Carlini <paolo.carl...@oracle.com> wrote: > Hi, > > > On 13/04/2018 19:14, Jason Merrill wrote: >> >> On Fri, Apr 13, 2018 at 1:05 PM, Paolo Carlini <paolo.carl...@oracle.com> >> wrote: >>> >>> Hi, >>> >>> On 13/04/2018 16:06, Jason Merrill wrote: >>>> >>>> On Fri, Apr 13, 2018 at 5:05 AM, Paolo Carlini >>>> <paolo.carl...@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. >>> >>> Basing on my analysis, that's easy to do, in convert_to_integer_1. >> >> Are we passing an error_mark_node down into convert_to_integer_1? >> Where are we folding away the VAR_DECL? > > That convert gets a NOP_EXPR with the VAR_DECL for 'j' as argument and > returns the error_mark_node.
Ah, I see. The problem is that even though convert_to_integer_1 was called with dofold false, we lose that when it calls convert(). Why not recurse directly to convert_to_integer_1 with the underlying type? That would avoid the undesired folding. Jason
