[patch i386]: Sibcall tail-call improvement and partial fix PR/60104

Iain Sandoe iain@codesourcery.com
Mon Sep 15 16:01:00 GMT 2014

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...


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.


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.


More information about the Gcc-patches mailing list