Re: Linux and aliasing?

[Joe Buck <jbuck@Synopsys.COM>]

Mark writes:
> > The only affect on your code will be that some optimizations that used
> > not to happen, but would with -fstrict-aliasing, will still not
> > happen.  What's the big deal?  If -fstrict-aliasing had never been
> > implemented, you wouldn't be complaining would you?  So, we've
> > improved GCC, and we've preserved the old behavior.

Linus writes:
> Oh, you don't expect me to complain about bad code generation when I know
> gcc could do better?

Oh, don't worry, we expect you to complain, and in a rude and insulting
matter at that.  We're used to it.  It seems that you were a nicer guy
before you had so many worshippers.

> Why do you have a "-O" flag at all if you think people don't care about
> performance?

Mark put in strict-aliasing because it is a big performance win.  Of
course he cares about performance.  The ISO rules were written in the
way they were written precisely to enable this performance improvement.

> I'd love to have the alias extensions, but I don't think it should be a
> per-file global setting. Sure, I can just be silent, but if you expect all
> egcs users to just sit idly when you do silly things, why do you bother
> making pre-releases available at all? You obviously don't care about the
> feedback you get from real users.

More rudeness and insults.  Of course we care.  Why do you insist on
talking to us like that?

> Sure, I can live with -fno-strict-aliasing. But I'm also really saddened
> by all the lawyers like you who think that standards are somehow more
> important than programmers. 

A compiler will do better the more aliasing possibilities it can
eliminate.  Mark used the ISO rules to determine what the set of
eliminatable aliases is.  You want to change this set to a smaller set, so
your programs will continue to work.  I understand that, I even
sympathize.  But you seem blind to the fact that this will inevitably make
some (possibly many) ISO-valid programs slower.  Possibly, with the right
rules, this set of slowed-down programs can be made very small.  Maybe
someone can donate a patch that will do this right.  But it's non-trivial,
and needs to be done carefully.

> I can see technical arguments. An argument of "it's really too painful to
> do" I can understand (preferably with an explanation, but hey, I don't
> mind getting told that it's too hard to explain). I use that argument
> every day myself. 

See above, or find someone to submit working code (you would ask this
in an equivalent situation on the kernel list).

> I think it's a damn shame that instead of technical arguments _everything_
> revolves around people reading the standard as if it was the bible, and
> trying to make people feel guilty for not really caring.

The standard is not arbitrary: it is the way it is for technical reasons,
specifically to make C a suitable language for numerical computation.
Without such rules serious number-crunchers have to switch to Fortran.

> just want to get good code without having to do magic contortions, guys.

We could flip the default for the flag, so that people have to write
-fstrict-aliasing to get the optimization.  Had we done that, you
never would have noticed.