This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104
- From: Kai Tietz <ktietz70 at googlemail dot com>
- To: FX <fxcoudert at gmail dot com>
- Cc: Jeff Law <law at redhat dot com>, Iain Sandoe <iain at codesourcery dot com>, Mike Stump <mikestump at comcast dot net>, Kai Tietz <ktietz at redhat dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>
- Date: Thu, 18 Sep 2014 23:26:33 +0200
- Subject: Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104
- Authentication-results: sourceware.org; auth=none
- References: <1478265243 dot 5697739 dot 1400792508558 dot JavaMail dot zimbra at redhat dot com> <AD1FD69F-389F-47A9-83F5-7584696E2677 at comcast dot net> <20140915004309 dot GA29543 at gate dot crashing dot org> <95EF5F55-098D-49F3-B6E6-79C1316D5148 at comcast dot net> <C2DD5222-FD32-407B-95DD-74E8D434A42C at codesourcery dot com> <A4344E8F-58D4-48A1-A9BC-B4C38378A1D9 at gmail dot com> <541708CF dot 2000708 at redhat dot com> <C7CEDD5C-EE8B-4B7F-A6CC-7983A1824BBB at gmail dot com>
Hi,
it isn't true that I didn't replied to Iant. I did this on IRC. As I
explained there already, this hunk about thunks is more consolidation
of code-paths in that function, and not really part of a feature. As
this code-path isn't prominent mark being Darwin-code - and please
don't take me wrong, but it seems to be until now the only target
reporting this issues - and therefore I strongly see the issue to be
solved for Darwin. I don't see that this changes needs an additional
testcase demonstration on a already regression-tested target that it
doesn't break ... This is somehow like asking for gcc-testcase
demostration that gcc's darwin target isn't responsible for earth's
warming ...
Nevertheless I provided in the past already a patch which fixes the
issue well. As underlying issue seems to be that gotpcrel relocations
aren't suitable for call-instruction's address on Darwin's target. So
disallowing for this the use via the operand-check-predicate is the
right thing to do. As this prevents in all cases that for this target
such a construct might be generated even for none-thunk case, which
seems btw not being problematic at all.
I don't agree to revert that patch. Please provide a testcase, why my
suggested fix isn't suitable.
Regards,
Kai