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.
<snip>
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.
