Reorganize -ffast-math code.

[Brad Lucier]

Toon Moene wrote:
> 
> 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:

First of all, this was something of a joke.  However, there is
a serious side to this issue, which I will address here.

I think this is directly relevant to what I consider to be a fact:
that the gcc developers over the years have not implemented safe,
accurate floating point arithmetic, despite their best efforts.
But first, some commentary.

For the Ariane disaster and the Patriot Missile failure, let me
refer to

http://www.math.psu.edu/dna/disasters/

The Patriot Missile failed because a certain variable was declared
single precision, and accumulated round-off error during continuous
operation during the Gulf War caused targetting inaccuracies.

I don't have a reference handy for the Vancouver Stock Exchange
problem, but what happened was the following.  The VSE used
an IBM mainframe to compute its stock average, which was updated
after every trade.  IBM floating-point arithmetic is, as you know,
in base 16 and trucates, so after a few years the reported stock
index was significantly lower than the true stock index.

An English translation of the extremely well-written, honest, and
insightful report on the Ariane disaster, written by a committee
chaired by the eminent mathematician Jacques Louis Lions, president
of the College de France, can be found at

http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

The essence of the problem is as you said.  Now, this does not
differ *one iota* from the fact that gcc on i386 spills extended
precision registers to double precision on the stack.  In doing
so, it stores objects into slots that have less precision and
less range than the objects themselves.  This is *exactly* what
happened with Ariane.  And gcc does it in a way that (a) does
not notify the programmer that it is being done and (b) the
programmer cannot avoid even if he/she examines the generated
assembley code.  So, on the 386, I believe

int flag_Ariane_class_disaster_math_optimizations = 1;

is the default.  And there should be a way to set this flag
to zero.

Brad