On 21/12/2011 09:31, Miles Bader wrote:
2011/12/21 David Brown<david@xxxxxxxxxxxxxxx>:
My impression was that they were the same, or at least related, since the
calculations in the examples would probably be done in advance by the
compiler and reduced to simple assignments.
You can't depend on the values the compiler calculates at compile-time
anymore than you can depend on values calculated at runtime (after
all, a decent compiler will strictly emulate the behavior of the
target hardware when doing constant folding).
For constant values, especially those meeting certain criteria, things
are simpler. For instance, [positive] zero or smallish positive
integer values can be exactly represented by any reasonable
floating-point format, and no amount of copying around is going to
change them, even given typical FPU wackiness.
If the
compiler can guarantee consistent and expected results in cases like yours
involving simple assignments, then it would make sense to change the
"-Wfloat-equal" not to trigger in such situations. After all, the point of
the warning is to help users avoid code that might not do what it seems to
do - if it /does/ do the expected thing, then there is no need of a warning.
In other words, the best course (IMHO) is to fix -Wfloat-equal to eliminate
common false positives, and /then/ enable it by default.
The problem is that in many cases you simply can't tell, because you
don't know how a particular value was produced.
For instance, if you have code like:
float var = zot ();
if (var == 0.f)
blahblah ();
You often don't know what "zot" did to calculate it's return value.
If it just did "return 0.f;", then you're golden -- the comparison is
fine. However, if it did "return 1.f - fsin (1.f);", wellllll.....
One thing that might work would be to have the warning code look at
the local context before the comparison, and only warn if it saw that
one of values being compared is actually calculated, rather than being
a constant or coming from some non-local source. This would result in
a lot of false negatives, but that's better than false positives.
-miles
I understand the problem you are describing, and the challenges of it.
But I think I disagree a little on what you describe as false positives,
and how much of a problem they are. Basically, I believe that if you
can't be sure that the code is consistent and correct in all
circumstances, including different optimisation levels, then it's bad
code - and it is fair to give a warning. So I would want a warning on
your "zot" code regardless of how it is implemented - to my mind, that's
not a false positive even if zot() were a macro expanding to "0.f".
It's bad code style to rely on it, so give a warning.
I am more a fan of strict warnings than most people, and have often said
most warnings should be enabled by default - though I know perfectly
well that they won't be. I'm just evangelising for safer coding
practices, as I see them. In reality, of course, I'll just keep the
warning flag in my own makefiles.
mvh.,
David
