This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Reorganize -ffast-math code.

Brad Lucier wrote:

> Richard Henderson wrote:

> > Perhaps a future iteration should separate unsafe optimizations
> > into those valid except for NaNs (and perhaps -0?) and those that
> > can affect precision.

> Yes, I had thought of flag_inaccurate_math_optimizations
> and flag_unsafe_math_optimizations.  Or perhaps we could name
> them for past disasters caused by faulty floating-point:

> flag_Ariane_class_disaster_math_optimizations

Hmmm, let's not add all sorts of Urban Legends to (the cause of) this
crash - it resulted from storing a perfectly valid 64-bit floating point
number into a 16-bit integer.  Unfortunately, the integer part of the
floating point number needed more than 16 bits.

[ And this wasn't even the real cause of the disaster: that was due to
  exceeding the design limitation of the software that was developed
  for a different generation of rockets ]

In general, let's not ascribe to misunderstanding floating point
arithmetic what's simply using software beyond its (stated) design
limitations.  Even our numerical weather prediction model - which is
extremely tolerant of imprecise floating point arithmetic - can be
brought to a screeching halt when used in ways that were not foreseen by
its architects.  It does include some rough tests to intercept these
conditions, but even those can fail.

Toon Moene - - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77:
Join GNU Fortran 95: (under construction)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]