Jonathan Stone <jonathan@DSG.Stanford.EDU> writes:

> >gcc does this (assumes that two variables of different types can not
> >refer to the same object) not to blindly follow the standard, but
> >because it permits a number of optimizations which are not otherwise
> >permitted.
> 
> Yes, we know; no need to be condescending.

I apologize if I sounded condescending; it certainly was not my
intent.  Many people with widely varying backgrounds read technical
mailing lists.  I long ago adopted the practice of trying to provide
background information, to avoid confusion.

> And there's a good case
> that that *is* blindly following the standard, at least by certain
> local lights.  The issue isn't a strict legalese reading of the
> standard; its an issue of a culture of (pre-C99) C coding in embedded,
> or machine-dependent environments like OS kernels.

If I understand you correctly, what you are saying is that people who
write in embedded or machine-dependent environments have certain
expectations of C compilers, and that gcc is violating those
expectations by following the standard.  I can only reply that other
people have different expectations of C compilers.

> >These optimizations are off by default, but are turned on by default
> >at -O2 and greater.  You can turn them off using -fno-strict-aliasing.
> 
> I that's the root of the problem: having -fstrict-aliasing on by
> default for -O2.  IT seems pretty ill-considered to me, in that this
> *is* a language change (vis-a-vis previous versions of gcc).  I'd have
> argued to leave it off, unless explicitly compiling with -ansi.

To me it seems like a culture clash.  Some people code to the
standard, and expect gcc to optimize accordingly.  Then they complain
that the optimizations aren't very good.  Other people code to a
different notion of the language, and complain about over-
optimization.

My take on it is that there is, after all, a standard, and it is
reasonable for gcc to follow that standard by default when it
generates better code.  Naturally if this breaks old code there should
be an option to avoid the breakage if possible.

If you want to convince the gcc maintainers to change the default, and
require an option to get better optimizations for standard conformant
code, then go for it.

At the risk of sounding condescending, I'll point out that it is, of
course, possible to write the earlier example in a standard conforming
fashion.

Ian