Re: [PATCH] Fix constexpr-dtor3.C FAIL on arm

[Jason Merrill <jason@redhat.com>]

On 10/11/19 4:20 AM, Jakub Jelinek wrote:
> On Thu, Oct 10, 2019 at 05:38:21PM -0400, Jason Merrill wrote:
>>> FAIL: g++.dg/cpp2a/constexpr-dtor3.C  -std=c++2a (test for excess errors)
>>> Excess errors:
>>> /gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C:152:12:   in 'constexpr'
>>> expansion of '(& w13)->W7::~W7()'
>>>
>>
>> This also seems unrelated, but I'll take a look.
> 
> This is solely a location_t difference, comparing x86_64 and arm output
>   constexpr-dtor3.C: At global scope:
>   constexpr-dtor3.C:156:23:   in ‘constexpr’ expansion of ‘f4()’
> -constexpr-dtor3.C:156:24:   in ‘constexpr’ expansion of ‘(& w13)->W7::~W7()’
> +constexpr-dtor3.C:152:12:   in ‘constexpr’ expansion of ‘(& w13)->W7::~W7()’
>   constexpr-dtor3.C:88:34: error: inline assembly is not a constant expression
>      88 |   constexpr ~W7 () { if (w == 5) asm (""); w = 3; } // { dg-error "inline assembly is not a constant expression" }
>         |                                  ^~~
>   constexpr-dtor3.C:88:34: note: only unevaluated inline assembly is allowed in a ‘constexpr’ function in C++2a
> 
> constexpr int
> f4 ()
> {
>    W7 w13 = 5;
>    return 0;
> }
> 
> constexpr int x4 = f4 ();       // { dg-message "in 'constexpr' expansion of" }
> 
> Line 152 is the W7 w13 = 5; line, line 156 the x4 = f4 () line.
>  From warning POV, the arm locations are nicer, but see below.
> 
> The difference is in cxx_maybe_build_cleanup:
> 
>    /* build_delete sets the location of the destructor call to the
>       current location, even though the destructor is going to be
>       called later, at the end of the current scope.  This can lead to
>       a "jumpy" behavior for users of debuggers when they step around
>       the end of the block.  So let's unset the location of the
>       destructor call instead.  */
>    protected_set_expr_location (cleanup, UNKNOWN_LOCATION);
> 
> On x86_64 and most other targets, cleanup here (if non-NULL) is the
> CALL_EXPR, as destructor return type is void, but on arm, as the dtor return
> type is some pointer, the CALL_EXPR is wrapped into a NOP_EXPR to void.
> protected_set_expr_location then on x86_64 clears the CALL_EXPR location,
> but on arm only NOP_EXPR location.
> 
> The following patch (totally untested) should fix that.
> 
> For the warning location, perhaps we could special case destructor calls
> in push_cx_call_context (to offset the intentional clearing of location for
> debugging purposes), if they don't have location set, don't use
> input_location for them, but try to pick DECL_SOURCE_LOCATION for the
> variable being destructed?

Expanding the CLEANUP_EXPR of a CLEANUP_STMT could use the EXPR_LOCATION 
of the CLEANUP_STMT.  Or the EXPR_LOCATION of *jump_target, if suitable.

Jason