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
