Floating point performance issue

David Brown david.brown@hesbynett.no
Sat Dec 24 11:11:00 GMT 2011

On 23/12/11 21:02, Vincent Lefevre wrote:
> On 2011-12-20 22:52:12 +0100, David Brown wrote:
>> I understand what you are saying here - and I agree that it's very important
>> that any such choice is made clear and explicit.  But that's why a program's
>> makefile is part of its source code - compiler flags are an essential part
>> of the source.
> Very often there isn't a static makefile, for instance for all those
> programs built via the autotools: the compiler options are provided
> by the one who builds the program. Note that there has already been
> complaints because some program gave incorrect results due to the
> -ffast-math option provided by a 3rd-party (who didn't know that it
> shouldn't have been used for this program).
> BTW, I've found in my archives the following example I had posted:
> float x = 30.0;
> int main()
> {
>    if ( 90.0/x != 3.0)
>      abort();
>    return 0;
> }
> fails with -ffast-math (on x86).
> Note that more generally, depending on the application, one may be
> able to prove that the division is exact (e.g. when computing some
> determinant on simple data), so that the != should be perfectly safe
> in such a case.


I have read the rest of your post (and the next one) with interest - I'm 
just snipping here to save space.

It's quite clear that we are seeing a very different range of programs 
using floating point, and a different range of problems or questions 
around them.  You see a much wider range than me - it makes sense that 
default flags, settings and warnings on the compiler are picked to do a 
reasonable job for such programs.

I work on a more restricted type of program (mostly embedded 
programming) where the rules are stricter.  For example, a makefile or 
other clear and unambiguous indication of compiler flags is a 
requirement.  In my work, the code you wrote above is bad code - it 
doesn't matter if the floating-point comparison turns out to be 
consistent when used, it's still wrong.  So to me, there are no "false 
positives" with something like -Wfloat-equal.  I want to be warned on 
anything that even smells like it could be "dodgy" code.

And (regarding other examples in your posts) if floating-point code 
depends on things like the order of calculations, it is also wrong - 
thus "-ffast-math" will not affect the correctness of the program, but 
will sometimes greatly improve the speed.

I don't think I'm alone in wishing that more programmers used stricter 
coding practices - a great many bugs that cause software users grief 
could have been found if the authors used their compilers' warning 
flags, and fixed their code appropriately.  It is true that this would 
sometimes mean changing code that is actually correct, but looks wrong 
to the compiler - that's part of the cost.  In many such situations, the 
code would also look questionable to humans, and should be changed anyway.

But I know full well that this is not going to change.  So the default 
settings of the compiler provide the safest possible code in the widest 
possible circumstances, and programmers like me can use the flags to get 
the features they want.

More information about the Gcc-help mailing list