Re: PATCH: tree-ssa-sink breaks stack layout

[Richard Guenther <richard dot guenther at gmail dot com>]

On Sun, Apr 5, 2009 at 9:23 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Eric Botcazou wrote:
>>> I think we ought to separate this discussion into two parts:
>>>
>>> (1) What can we do to eliminate a serious defect in the short-term?
>>> This is a case of silently generating wrong code, with a simple,
>>> reasonable test case.
>>
>> This defect has been there for years though so I don't see the urgency.
>
> Has it been there for years with such a simple test-case? ?Or is it just
> that the same conceptual problem has been there for years? ?These aren't
> rhetorical questions; I was aware of the general issue years ago, but I
> hadn't seen it with a simple test case before.
>
> I'm not claiming extreme urgency, and if this test case is not a
> regression then a fix for 4.4 probably wouldn't be accepted anyhow.
> But, we shouldn't ignore wrong-code bugs just because they're old.
>
>>> There's nothing wrong with further papering-over of the problem, if that
>>> reduces the set of affected programs and we don't have a better
>>> short-term solution. ?An unachievable no-bugs solution should not be the
>>> enemy of an achievable fewer-bugs solution.
>>
>> Papering over it again will very likely delay its resolution again.
>
> If I understand correctly, you're arguing that delivering broken
> software to users is better than papering over a bug because the
> brokenness will motivate people to fix the underlying problem, resulting
> in a better long-term outcome. ?I can't see that very many users are
> going to agree that this is the attitude they'd like to see their
> compiler provider take. ?I also can't see that this helps GCC compete
> against other compilers.
>
> The reason that we've not fixed this problem is because it's hard. ?Is
> anybody committed to fixing this for 4.5? ?If not, there's no guarantee
> that it will be fixed in that timeframe. ?Isn't it better to reduce the
> impact of the bug, in case it's not in fact fixed?
>
> (For avoidance of doubt, I have no direct commercial interest in this.
> There's no CodeSourcery customer demanding that we get a fix for this
> into the FSF sourcebase, or anything like that. ?I'd just like to see
> FSF GCC releases work as well for people as possible, and I think that a
> conversation about how to deal with design bugs that don't have easy
> solutions is valuable.)

I agree with both of you.  May I suggest to provide our users with
a workaround, -fno-stack-slot-sharing, instead?

As of a proper fix in the 4.5 timeframe - I suggest that organizations
consider assigning ressources to fixing this problem, it's unlikely going
to be a volunteers effort to implement for example the suggestion
of delaying stack slot allocation until after scheduling.

Thanks,
Richard.