optimization bug in g77

[Jeffrey A Law]

  In message < 199902212341.PAA21225@adsl-206-170-148-33.dsl.pacbell.net >you wri
te:
  >     Jeffrey> For those codes which do trip the problem folks can
  >     Jeffrey> disable this optimization.
  > 
  > But, for most users, it's very difficult, if not impossible, to figure
  > out *what* optimization is causing the problem.  Most likely, they'll
  > compile a large program and find it behave unexpectedly, and just not
  > know why.  This reflects poorly on EGCS.
Good point.  Though given that this bug has been in gcc for ~10 years now
and we've probably had less than a dozen bugs says something about how often
it triggers.  Interestingly enough, most of the problems have shown up over
the last 18 months -- because our alias analysis is getting better and our
scheduler is getting more agressive.


  > I think it's a good deal more responsible to invert your suggestion:
  > disable the (known to be broken) optimization by default, and then
  > provide an option to *enable* it.  Thus, the "power users", who want
  > maximum speed, can know what they're getting into: the documentation
  > will say explicitly that the option is, in general, known to be
  > unsafe.
I think this is a little overly conservative, but I can live with it.  
-f[no]structure-alias or something like that?  

The docs might look something like:

-fstructure-alias:
Allow the compiler to assume that a structure or array reference at a 
varying address can never conflict with a scalar reference at a fixed
address.  In the vast majority of programs this is safe, but in a small
number programs a bug in GCC's alias analysis can cause incorrect code
generation.  Thus the default is -fno-structure-alias.

This option is only found in the egcs-1.1.2 release.  egcs-1.2 and newer
releases have fixed the alias analysis bug and always assume that a
structure/array reference at a varying address can never conflict with
a scalar reference at a fixed address.

Jeff