From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75665 invoked by alias); 16 Oct 2019 20:36:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 75641 invoked by uid 89); 16 Oct 2019 20:36:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Oct 2019 20:36:21 +0000 Received: from mail-oi1-f199.google.com (mail-oi1-f199.google.com [209.85.167.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AA18F85538 for ; Wed, 16 Oct 2019 20:36:19 +0000 (UTC) Received: by mail-oi1-f199.google.com with SMTP id 74so129822oie.3 for ; Wed, 16 Oct 2019 13:36:19 -0700 (PDT) MIME-Version: 1.0 References: <20191011082001.GR15914@tucnak> <38e25fad-c315-5f23-7e06-c92125082621@redhat.com> <20191016162755.GN2116@tucnak> In-Reply-To: <20191016162755.GN2116@tucnak> From: Jason Merrill Date: Wed, 16 Oct 2019 21:03:00 -0000 Message-ID: Subject: Re: [PATCH] Fix constexpr-dtor3.C FAIL on arm To: Jakub Jelinek Cc: Christophe Lyon , Romain Geissler , gcc-patches List , Andrew Sutton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg01227.txt.bz2 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 r= eturn >>> 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 locatio= n, >>> 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 chan= ge > anything, the diagnostics was still > constexpr-dtor3.C:16:23: in =E2=80=98constexpr=E2=80=99 expansion of = =E2=80=98f4()=E2=80=99 > constexpr-dtor3.C:16:24: in =E2=80=98constexpr=E2=80=99 expansion of = =E2=80=98(& w13)->W7::~W7()=E2=80=99 > constexpr-dtor3.C:5:34: error: inline assembly is not a constant expressi= on > 5 | constexpr ~W7 () { if (w =3D=3D 5) asm (""); w =3D 3; } // { d= g-error "inline assembly is not a constant expression" } > | ^~~ > constexpr-dtor3.C:5:34: note: only unevaluated inline assembly is allowed= in a =E2=80=98constexpr=E2=80=99 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