This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix ICF with error/warning attribute (PR ipa/84628)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Martin Liška <mliska at suse dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 2 Mar 2018 09:21:13 +0100
- Subject: Re: [PATCH] Fix ICF with error/warning attribute (PR ipa/84628)
- Authentication-results: sourceware.org; auth=none
- References: <20180301230909.GT5867@tucnak> <alpine.LSU.2.20.1803020858140.18265@zhemvz.fhfr.qr> <20180302081040.GA5867@tucnak> <alpine.LSU.2.20.1803020912590.18265@zhemvz.fhfr.qr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Mar 02, 2018 at 09:15:07AM +0100, Richard Biener wrote:
> You probably need a virtual return thunk as otherwise we expand them
> directly to asm?
I was trying x86_64 -m32 -fpic regparm (3) method with thunks so that
the asm isn't emitted. But the thunk was still using call to .LTHUNKN
rather than the actual method FUNCTION_DECL. Perhaps on targets without
proper alias support...
> > Would you prefer just being silent in all thunks?
>
> Yes, I think all warnings from thunks are ultimately going to be bogus...
Ok, I'll change the patch.
> > That said, wonder about thunks (the non-ICF ones) from false-negative
> > diagnostic point as well, if I have some method with error/warning attribute
> > and call a thunk instead, wonder if we get the diagnostic or not, thunks
> > likely don't have the attribute copied over to them.
>
> True...
>
> I guess we should not warn from thunks but instead move those attributes
> to the thunks so see if those get called in the end.
Or in the expr.c code look through thunks to find the underlying function
and take DECL_ARGUMENTS from there.
Jakub