Kaveh R. GHAZI wrote: > 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.
I agree with that statement. As some have pointed out, we have a set of wrong-code bugs in GCC, and many of them go away with -O0. So, we could disable everything except -O0 and improve quality -- but we know that's silly. So, we know there's a continuum, and that -- to some extent -- we're willing to trade bugs for speed. Unfortunately, this class of bugs is the worse kind: silent, wrong code, on multiple platforms, without any options other than "-O2". This class of bugs often defies isolation by casual developers because small perturbations of the source can cause the bug to go away and because no warnings are issued by the compiler about suspect code. After getting a couple of reports from customers, CodeSourcery made the decision to take the performance hit in our 4.1.x toolchains, and I think that was the right call for us. I don't know how to evaluate Danny B's claims that these things are rare. We don't have nearly as a big a customer base as Red Hat or SuSE, and our customer base compiles a different class of applications on different hardware, so that may explain the differences. To be honest, my instinct for the FSF is to take the 4% hit and get rid of this nasty class of bugs. Users measure compiler quality by more than just floating-point benchmarks; FP code is a relatively small (albeit important, and substantial) set of all code. That's why I asked Danny for the patches in the first place. However, as people have questioned that decision, I'm trying to gather data. We've got one key piece of data: the safety patch cost 4% on Intel chips. Next, I'd like to see 4.1.x vs. 4.2.0 numbers; that would tell me whether a user upgrading from 4.1.x to 4.2.0 will see a regression, or if the 4% will be absorbed by other improvements. If someone with a different chip is willing to provide the same measurements, that would help eliminate Intel-specific characteristics in the data as well. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
