This is the mail archive of the
mailing list for the GCC project.
Re: GCC 4.1.0 Released
H. J. Lu wrote:
> Here are diffs of SPEC CPU 2K between before and after with gcc 4.1
> using "-O2 -ffast-math" on Nocona:
Steven's right; this is clearly a new feature. HJ's also right; we've
made exceptions before.
Like Steven, I would like to see what the difference is between
-mtune=generic and -mtune=nocona. If there is not much difference, then
that's an argument against a backport; just tell users to add
-mtune=nocona. It's up to architecture maintainers to get defaults set
well for their systems in advance of releases.
I'd also like to hear from our IA32 maintainers.
I'm going to set the bar here relatively high on several grounds:
1. I've just been reminded, once again, of the dangers of "safe"
patches; c.f., the Alpha OSF threads patch for 4.1.0 which turned out to
break NetBSD. (Fortunately, that configuration was badly enough broken
before the patch that I don't think any terribly serious damage was
done; 4.1.1 will presumably have Roger's patches which fix all of that.)
I'm in no way criticizing Roger, and it was I who approved the patch;
however, the key point is that danger lurks everywhere.
2. IA32 is one of, if not the, most popular GCC architectures. On the
one hand, yes, that argues for making it perform well there; on the
other, it also argues very strongly for stability. Effectively changing
the default optimization behavior on a release branch substantially
invalidates previous validation done on that branch.
3. Slippery slope. Every time I bend the rules, I get criticized for
bending the rules, and I get besieged by people who want other rules
bent, and then I get criticized for bending rule X for person A, but not
rule Y for person B. I've got a thick skin, and I feel omfortable
exercising my own non-algorithmic discretion to do what I believe is the
right thing. But, I will also be sensitive to the developer community's
desire for predictability of decision-making.
(650) 331-3385 x713