This is the mail archive of the
gcc-patches@gcc.gnu.org
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: Mon, 06 Apr 2009 10:17:42 -0700
- Subject: Re: PATCH: tree-ssa-sink breaks stack layout
- References: <49D25676.6010808@codesourcery.com> <200904052108.56726.ebotcazou@adacore.com> <49D90534.4050003@codesourcery.com> <200904061913.15880.ebotcazou@adacore.com>
Eric Botcazou wrote:
>> 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.
>
> It depends on what you call "broken software". Would GCC stop being
> "broken software" if we paper over this particular bug?
No, but it would be less broken. Obviously, these are all questions of
degree. (For the record, I certainly don't consider GCC "broken"
because of this bug -- or any other bug it currently has. However,
users are often less charitable.)
> What about papering over the hundreds of other bugs we know GCC
> contains? We would need some criterion.
If we can fix bugs properly, we should. If we can't, papering over the
bug is better than nothing. How desirable it is to paper over the bug
depends on how severe it is (i.e., the level of pain imposed on affected
users) and how common it is (i.e., how many users are likely to be
affected). The more severe, and the more common, the more desirable.
In this case, we have a severe, but probably relatively uncommon, bug.
So that's an intermediate case.
>> 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?
>
> This bug has been known for years and seems to occur extremely rarely
> in pratice, so why rushing to paper over it now?
That's a mischaracterization. Nobody's "rushing" to do anything. I've
certainly not demanded that we stop everything to fix this bug! My
objection is to the attitude that because this is hard to fix correctly,
we shouldn't look for inferior, but easier-to-implement, fixes.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713