From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) by sourceware.org (Postfix) with ESMTPS id 295093858D37 for ; Tue, 21 Feb 2023 22:27:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 295093858D37 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=acm.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qv1-xf31.google.com with SMTP id bo10so5758966qvb.12 for ; Tue, 21 Feb 2023 14:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=lyCQGj9Jm1PtgvGZRJgepNQB5+dTTQDsMLwXe7PjhCo=; b=Ma/nUu5bOR/eaUALy8/r0dbcURE3Hx9LeNnNoUsNssPDZQYe9NtH0nOVImJQ+6RMQx vNzUZJCn64Mg2ZbTVTKElmg0mAs8aRBgnG4U52FLMDdKM4DxRxh7sIJsuzAeVXx1mVtH xop+XfuJPcScXhtezjWQK7Otov1WPgaAgGVVTnLseOo9LCSJND7QtXlU2jAn+an0X8T1 b+rW+qBXkXUgZVHMHduDWKVwpzYUBc23vElRekuHBwGa5wsHoaKysP1V0C/KPNQy0tMe LDOFPl1dnXDcRdAxrkIQnAy3R9R7mR+sOl1a5sqfD/lySXwceLyevtU7DnuDt1ci/mGt Hv2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lyCQGj9Jm1PtgvGZRJgepNQB5+dTTQDsMLwXe7PjhCo=; b=1eIx+tBbyk1oAK+hmBSVeKwYu7KsJd7mrwgcbGmat+Mx+dUB/dxtUmDGhZpgqv+mNy UsNL1fJi7R7kT5M2bpfAz5gJgUhTWBtXwe5cvLOgnu2//ZolFyZtp8PyXKE+thO3MNrc dxOH5RzifMR1xxxEECIaJew/FJKQ12rZ+npLl7mmqh7xocYGTgwpplJvi5s5h3uYBXb5 IDfl+wagsqngJ/qNMWXU/x69NmDH1qApVtz3ECsuGzjloYSdDJBsggSHTJVmqbUnT6kf gt2uWac2D5nIcG7hxSOGWvwz5ycBBfj27DqnomsjKiORUFSK/k3U9qX9vYLV+3S9L6hN NfjA== X-Gm-Message-State: AO0yUKWHhX+BTstgxXY7c+QjqmtxidSOUO8wMKsm6/6NJTjDZgbNQSwc 8ylOh77XHS/YH1wiF7xSdNg= X-Google-Smtp-Source: AK7set+Vk1cHYLNL2Hq0Cu2MC4GRnmu0d6nZz9qpgdF6moSUGPPc6ouzo0CkRGG1forTsDB9QP7Dxw== X-Received: by 2002:a05:6214:29c8:b0:56f:1b7e:d87f with SMTP id gh8-20020a05621429c800b0056f1b7ed87fmr11776634qvb.34.1677018443437; Tue, 21 Feb 2023 14:27:23 -0800 (PST) Received: from ?IPV6:2601:19c:527f:bfd0::1? ([2601:19c:527f:bfd0::1]) by smtp.googlemail.com with ESMTPSA id 193-20020a370aca000000b00741b312c899sm1918267qkk.6.2023.02.21.14.27.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Feb 2023 14:27:23 -0800 (PST) Sender: Nathan Sidwell Message-ID: <4c0b5df3-b7ec-9edc-e9ad-2268ad623dc5@acm.org> Date: Tue, 21 Feb 2023 17:27:21 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: C++ modules and AAPCS/ARM EABI clash on inline key methods To: Richard Earnshaw , Alexandre Oliva , gcc-patches@gcc.gnu.org Cc: nickc@redhat.com, richard.earnshaw@arm.com, ramana.gcc@gmail.com, kyrylo.tkachov@arm.com References: <05cf53e4-af4d-7af1-da4b-3635345db9bf@foss.arm.com> Content-Language: en-US From: Nathan Sidwell In-Reply-To: <05cf53e4-af4d-7af1-da4b-3635345db9bf@foss.arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3037.2 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2/21/23 11:31, Richard Earnshaw wrote: > I started looking at this a few weeks back, but I was a bit confused by the > testcase and then never got around to following up. > > The Arm C++ binding rules normally exclude using an inline function definition > from being chosen as the key function because this not uncommonly appears in a > header file; instead a later function in the class is defined to take that role, > if such a function exists (in effect an inline function is treated the same way > as if the function definition appeared within the class definition itself). > > But in this class we have only the one function, so in effect this testcase > appears to fall back to the 'no key function' rule and as such I'd expect the > class impedimenta to be required in all instances of the function.  That doesn't > seem to be happening, so either there's something I'm missing, or there's > something the compiler is doing wrong for this case. > > Nathan, your insights would be appreciated here. Right in the ARM ABI we'll be emitting the vtables etc in any TU that might need them. IIUC that's any TU that creates (or destroys?) an object of type Visitor (or derived from there). That source file does not do that. I see I didn't add a testcase where the only vfunc was declared inline in the class itself. Thus there's no generic-abi equivalent of ARM's behaviour. I don't think arm's behavior should be an xfail, instead restrict the checks to !arm-eabi nathan > > R. > > >> >> for  gcc/testsuite/ChangeLog >> >>     PR c++/105224 >>     * g++.dg/modules/virt-2_a.C: XFAIL syms on arm*-*-*. >> --- >>   gcc/testsuite/g++.dg/modules/virt-2_a.C |    6 +++--- >>   1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/gcc/testsuite/g++.dg/modules/virt-2_a.C >> b/gcc/testsuite/g++.dg/modules/virt-2_a.C >> index 580552be5a0d8..b265515e2c7fd 100644 >> --- a/gcc/testsuite/g++.dg/modules/virt-2_a.C >> +++ b/gcc/testsuite/g++.dg/modules/virt-2_a.C >> @@ -22,6 +22,6 @@ export int Visit (Visitor *v) >>   } >>   // Emit here >> -// { dg-final { scan-assembler {_ZTVW3foo7Visitor:} } } >> -// { dg-final { scan-assembler {_ZTIW3foo7Visitor:} } } >> -// { dg-final { scan-assembler {_ZTSW3foo7Visitor:} } } >> +// { dg-final { scan-assembler {_ZTVW3foo7Visitor:} { xfail arm*-*-* } } } >> +// { dg-final { scan-assembler {_ZTIW3foo7Visitor:} { xfail arm*-*-* } } } >> +// { dg-final { scan-assembler {_ZTSW3foo7Visitor:} { xfail arm*-*-* } } } >> >> -- Nathan Sidwell