Re: type based aliasing again

[David Ronis <ronis at onsager dot chem dot mcgill dot ca>]

Time to add my 2 cents.  

First, several of the posts have questioned how "real" the need is for
some modification/flag/warning associated with -fstrict-aliasing.  In
the last few weeks I've been noticed:

1.  Instabilities in the linux kernel (2.2.xx with xx>10) triggered by
    compiling without -fno-strict-aliasing

2.  Problems with perl-5.00561; specifically, a runaway memory
    condition in the pattern recognition test that crashed my machine.
    To be sure, the crash was my fault for not having limits set on
    memory use.  With -fno-strict-aliasing the problem didn't occur.

3.  Possible problems with the gtk+ libraries.  [I'm less sure here
    since the app I'm trying to build doesn't work yet with or without
    the -fno-strict-aliasing flag].

4.  Some problem with the your own java library (this was mentioned on
    the list a little while ago).

Since these are building-block programs on many systems, I'd call the
problem serious.

Personally, I'd prefer to have the more aggressive optimization on by
default, especially since it is what the legalease in the standard
wants.  On the other hand, given the history, to not have a warning
flag, something like -Waliasing , no matter how imperfect, seems like
cruel and unusual punishment.  Many of us end-users often grab some
poorly maintained legacy code and simply configure/make/make install.
Is the expectation really to trace through thousands of lines of code,
if it doesn't work, in the hope that it might be an aliasing problem?
Even a hint of where suspicious aliases occur would be invaluable in
this event and even if the warning picks up lots of false-alarms.

David