This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: tree-ssa-sink breaks stack layout
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Ian Lance Taylor <iant at google dot com>, Richard Guenther <richard dot guenther at gmail dot com>, Sandra Loosemore <sandra at codesourcery dot com>, Daniel Berlin <dberlin at dberlin dot org>
- Date: Sun, 05 Apr 2009 12:23:32 -0700
- Subject: Re: PATCH: tree-ssa-sink breaks stack layout
- References: <49D25676.email@example.com> <firstname.lastname@example.org> <49D8FB92.email@example.com> <firstname.lastname@example.org>
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.)
(650) 331-3385 x713