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: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Martin Liška <mliska at suse dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 2 Mar 2018 09:31:16 +0100 (CET)
- 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> <20180302082113.GC5867@tucnak>
On Fri, 2 Mar 2018, Jakub Jelinek wrote:
> 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.
If that's easily possible that sounds good as well of course.
Richard.