On Tue, 20 Feb 2007, Daniel Jacobowitz wrote: > On Tue, Feb 20, 2007 at 06:23:14PM -0500, Kaveh R. GHAZI wrote: > > No it doesn't need stating, at least not for me. :-) Sure nobody likes > > bugs/miscompilations, but all compilers have them. We evaluate how > > serious they are and whether a performance hit from a bug fix is worth it. > > My understanding is that 4.1 has this very same bug, and it hits about as > > often as it does in 4.2. See the end of this message: > > http://gcc.gnu.org/ml/gcc/2007-02/msg00432.html > > > > If so, then it can't be too bad IMHO. That was the context within which > > I made my statement. And if that holds, I continue to stand by it. > > On the other hand, I consider this a fairly serious bug in 4.1 (and > I've seen customers encounter it at least twice off the top of my > head). It depends what your tolerance for wrong-code bugs is. > Daniel Jacobowitz
My tolerance is pretty low. I'm relying on the fact that the bug occurs rarely in real code. I'm trying to reconcile your statement about customer feedback with Daniel B's claim here: http://gcc.gnu.org/ml/gcc/2007-02/msg00476.html He said: "I'm still of the opinion that even though you can write relatively simple testcases for them, they are actually pretty rare. In most of the bugs, it is in fact, the absence of any real code (or local variables in one case) that triggers the bad result. Anything more complex and we get the right answer." We have to make a judgement about how serious this bug really is. Some people seem to think correctness *always* wins, I don't like absolutes, they are too limiting. I don't at all think performance always wins, but correctness of rare corner cases which comes at high costs must be evaluated in context. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]