This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Adjust empty class parameter passing ABI (PR c++/60336)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Marek Polacek <polacek at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Fri, 27 Oct 2017 12:38:19 +0200
- Subject: Re: Adjust empty class parameter passing ABI (PR c++/60336)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jakub at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BE741CD4C2
- References: <20171027100056.GE12792@redhat.com> <alpine.LSU.2.20.1710271226420.8202@zhemvz.fhfr.qr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Oct 27, 2017 at 12:31:46PM +0200, Richard Biener wrote:
> I fear it doesn't work at all with LTO (you'll always get the old ABI
> if I read the patch correctly). This is because the function
> computing the size looks at flag_abi_version which isn't saved
> per function / TU.
>
> Similarly you'll never get the ABI warning with LTO (less of a big
> deal of course) because the langhook doesn't reflect things correctly
> either.
>
> So... can we instead compute whether a type is "empty" according
> to the ABI early and store the result in the type (thinking of
> doing this in layout_type?). Similarly set a flag whether to
> warn. Why do you warn from backends / code emission and not
> from the FEs? Is that to avoid warnings for calls that got inlined?
> Maybe the FE could set a flag on the call itself (ok, somewhat
> awkward to funnel through gimple).
Warning in the FE is too early both because of the inlining, never
emitted functions and because whether an empty struct is passed differently
from the past matters on the backend (whether its psABI says it should be
not passed at all or not).
Perhaps if empty types are rare enough it could be an artificial attribute
on the type if we can't get a spare bit for that. But computing in the FE
or before free_lang_data and saving on the type whether it is empty or not
seems reasonable to me.
Jakub