On 10/16/19 12:27 PM, Jakub Jelinek wrote:
On Fri, Oct 11, 2019 at 04:14:16PM -0400, Jason Merrill wrote:
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.
The already previously posted patch (now attached as first) has now been
bootstrapped/regtested on x86_64-linux and i686-linux, and regardless if we
improve the location or not should fix the arm vs. the rest of the world
difference. Is that ok for trunk?
OK.
As for CLEANUP_STMT, I've tried it (the second patch), but it didn't change
anything, the diagnostics was still
constexpr-dtor3.C:16:23: in ‘constexpr’ expansion of ‘f4()’
constexpr-dtor3.C:16:24: in ‘constexpr’ expansion of ‘(& w13)->W7::~W7()’
constexpr-dtor3.C:5:34: error: inline assembly is not a constant expression
5 | constexpr ~W7 () { if (w == 5) asm (""); w = 3; } // { dg-error "inline
assembly is not a constant expression" }
| ^~~
constexpr-dtor3.C:5:34: note: only unevaluated inline assembly is allowed in a
‘constexpr’ function in C++2a
as without that change.
That's because the patch changes EXPR_LOCATION for evaluation of the
CLEANUP_BODY, but it should be for evaluation of CLEANUP_EXPR instead.
Jason
