Re: type based aliasing again

[Nick Ing-Simmons <nik@tiuk.ti.com>]

Geoff Keating <geoffk@ozemail.com.au> writes:
>Nick Ing-Simmons <nik@tiuk.ti.com> writes:
>
>> Yes it does. Both -ffast-math and -fstrict-aliasing turn on optimizations
>> which may break existing code.
>
>Every optimisation that changes the ordering of memory accesses may
>break existing code, in the presence of threads or signals.

True. But such code while it may "exist" is unlikely to work correctly 
on different architectures with/without -O etc. As such breaking such code
is not as likely to surprise anyone that happens to be using it.

This is a different class of "existing code" than that which is broken 
by acting upon -fstrict-aliasing. Neither Linux kernel, nor perl, nor 
emacs is fragile in that sense. 

The "snag" with -fstrict-aliasing is that what it breaks is a commonly used
"trick" (C as architecture independant assembler) which has become entrenched 
in the code base. There are going to be lots of "close to the machine" bits
of code which have worked fine for years and are not actively maintained
which get bitten.

That said I don't really mind which way the default goes. But having 
it differ between -ON and -ON+1 is going to confuse people more than 
having to say -fno-strict-aliasing. (I would guess about 1/2 of 
./configure generated Makefiles generate -O2 for GCC.)

For new or fixed-up code I would prefer an attribute scheme so that I did 
not have to penalize an entire file just for (ab)use in one hot-spot.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.