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: Iain Sandoe <iain at codesourcery dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: FX <fxcoudert at gmail 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: Mon, 15 Sep 2014 17:01:44 +0100
- 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>
Hi Jeff,
On 15 Sep 2014, at 16:42, Jeff Law wrote:
> On 09/15/14 05:25, FX wrote:
>>> Perhaps it would be safer simply to revert that hunk of the original patch unless/until (1) and (2) above are addressed?
>>
>> Given that the original patch addresses “only” a missed-optimization (and causes ice-on-valid), it makes sense to me.
> What I think we need is folks with an understanding of those systems to chime in with the information Kai needs to fix the problem. I don't recall seeing that, so if I missed it, feel free to point me to it.
The information to date is in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387
> I'd rather not start going backwards and reverting because we simply haven't done the digging to really understand the issues on other other ports.
Well, I'm not in the habit of suggesting reverting parts of patches normally, however...
1)
The first problem I am having is finding *any* platform test (other than Darwin) that exercises the code in question (and it fails on Darwin).
Ergo, the situation is not about "other ports" - but where is the testcase that exercises this new code on some reference port?
FWIW: When the problem first occurred, I placed a gcc_abort in that position and ran bootstrap and check on x86-64-linux without the abort being triggered (so I don't think that saying the patch "passed regression testing on x86-64-linux" is helping much here).
If Darwin has a bug, fine - then we will go hunting it - but first we need something solid to base the investigation on.
2)
Regardless of port-related issues, the code in question has been significantly altered - but the comment describing it has not been adjusted - at the least the comment should be amended to state the new intent of the code.
thanks
Iain