Re: type based aliasing again

[craig AT jcb-sc.com]

>What would be wrong with -fno-strict-aliasing the default for -O(1,2,3,s) and
>have a new -O4 enable it (ie "-O4" == "-O3 -fstrict-aliasing").  This would
>guarantee all current software and their make files to still generate correct
>code, yet still make it extremely easy to enable the optimizations for fully
>ISO/ANSI compliant software.
>
>Its seems like far too easy a solution to me.

It's certainly within a reasonable "umbrella" approach of having
increasing optimization levels be about increasing reliance on
the code strictly conforming to the pertinent standard, even its
"tricky bits".

The biggest problem I see with it right now is that we haven't
exactly taken that "umbrella" approach in the past in a consistent
way.

If we start now, there'll be some hiccups -- people who currently
compile and run their code quite happily at -O2 or -O3 would
presumably experience a drop in performance when using a new
version of GCC that changes (practically, reverts) to assuming
of -fno-alias-analysis, as compared to 2.95, which assumes
the opposite.

The other problem I see with relying on -O levels to denote
rough degree of conformance to language standard is that we
already use it to (again, roughly) indicate willingness to
tolerate long compile times and (or at least in the past) to
indicate willingness to run recently coded, or not-entirely-trusted,
optimization phases.

The former problem would be short-term, and the latter problem
we could address using some other convention for one or more
of the meanings.  Perhaps we could introduce a general-purpose
option such as `-fconformance=LEVEL', where LEVEL could be "loose",
"typical", "strict", "pristine", in that order, and have -falias-analysis
be triggered at levels "strict" and "pristine".  Not exactly ideal,
but roughly conforms with the general thrust of some of the concerns
expressed in this and other threads....

        tq vm, (burley)