Re: -fstrict-fp-semantics (was Re: numerical instability and estimate-probability)

[Brad Lucier <lucier at math dot purdue dot edu>]

> > I presume that there is so little time in gcc spent in fp that the
> > performance penalty wouldn't matter.
> Agreed - but gcc only solution is to put in that volatile keyword.
> It brings stablity I need.  I tought you are shooting for sollution
> for numeric programmers.

I'm shooting for a solution.  Period.  Let the numeric programmers
decide for themselves whether it is worth the performance trade-off.
I'm suggesting that for gcc, it would be worth a tiny amount of
compile-time performance hit to get good bootstrap comparisons.

> Imagine followin code.
> 
> a=expression;
> t=a;
> 
> where a is an global variable and t is local.  If you avoid the redundant
> load/store pair, you avoid the truncating and t will differ.

Unfortunately, on a machine where all calculations are done to extended
double range (if not precision), and if a is smaller than an extended
double, than for predictable fp semantics you need to do the store.

Look, there are many, many places in the gcc code that say things like
"FP is not associative, so don't apply the following transformation" etc.
To make this final fix you just need to extend these tests to a few more 
places.

> The loop optimization basically deals with such a sequence.

And, as you describe it, it changes the answer.  There should be an
option to gcc that says "I want to be able to predict from the code I
write what the answer will be.  Don't change it."

Brad