public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nathan Sidwell <nathan@acm.org>
To: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>,
	Alexandre Oliva <oliva@adacore.com>,
	gcc-patches@gcc.gnu.org
Cc: nickc@redhat.com, richard.earnshaw@arm.com, ramana.gcc@gmail.com,
	kyrylo.tkachov@arm.com
Subject: Re: C++ modules and AAPCS/ARM EABI clash on inline key methods
Date: Tue, 21 Feb 2023 17:27:21 -0500	[thread overview]
Message-ID: <4c0b5df3-b7ec-9edc-e9ad-2268ad623dc5@acm.org> (raw)
In-Reply-To: <05cf53e4-af4d-7af1-da4b-3635345db9bf@foss.arm.com>

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


      parent reply	other threads:[~2023-02-21 22:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-31  7:32 Alexandre Oliva
2022-04-05  4:53 ` Alexandre Oliva
2023-02-17  6:09   ` Alexandre Oliva
2023-02-21 16:31     ` Richard Earnshaw
2023-02-21 16:48       ` Richard Earnshaw
2023-02-22 19:57         ` Alexandre Oliva
2023-02-23 10:14           ` Richard Earnshaw
2023-02-23 17:12             ` Alexandre Oliva
2023-02-23 21:20               ` Alexandre Oliva
2023-02-24 10:23                 ` Richard Earnshaw
2023-02-24 10:30                   ` Iain Sandoe
2023-02-24 14:39                   ` Alexandre Oliva
2023-02-21 22:27       ` Nathan Sidwell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4c0b5df3-b7ec-9edc-e9ad-2268ad623dc5@acm.org \
    --to=nathan@acm.org \
    --cc=Richard.Earnshaw@foss.arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=kyrylo.tkachov@arm.com \
    --cc=nickc@redhat.com \
    --cc=oliva@adacore.com \
    --cc=ramana.gcc@gmail.com \
    --cc=richard.earnshaw@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).