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.


Reply via email to