Richard Guenther wrote:
On 2/21/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
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.
Of course the speed of a compiler is measured on testcases where
speed matters - and this is usually FP code. Now based on this reasoning
we could (as CodeSourcery probably did) enable -fno-strict-aliasing by
default, which fixes the class of 4.1.x bugs we are talking about. With
leaving the possibility for the user to specify -fstrict-aliasing and get
back the speed for FP code with the risk of getting wrong-code.
Now, the realistic choices for 4.2.0 as I see them are, in order of my
personal preference:
1) Ship 4.2.0 as is
2) Ship 4.2.0 with the aliasing fixes reverted
3) no more reasonable option. Maybe don't ship 4.2.0 at all.
IMHO The worst would be skipping 4.2, it is even worse than rebranching.
But It looks now that the 1st option is the most reasonable.
According Grigory Zagorodny from Intel, 4.2 vs 4.1.2 has 19% better
performance on SpecFp2006. So I guess 4-5% degradation because of
aliasing patch is not a big deal for the release. 4.2 will be better
4.1 in any case with the performance point of view.
http://gcc.gnu.org/ml/gcc/2007-02/msg00512.html