Why does NaN - NaN == 0.0 with the Intel C++ Compiler?

The default floating point handling in Intel C++ compiler is /fp:fast, which handles NaN's unsafely (which also results in NaN == NaN being true for example). Try specifying /fp:strict or /fp:precise and see if that helps.

This . . . can't be right, right? My question: what do the relevant standards (ISO C, ISO C++, IEEE 754) say about this?

Petr Abdulin already answered why the compiler gives a 0.0 answer.

Here is what IEEE-754:2008 says:

(6.2 Operations with NaNs) "[...] For an operation with quiet NaN inputs, other than maximum and minimum operations, if a floating-point result is to be delivered the result shall be a quiet NaN which should be one of the input NaNs."

So the only valid result for the subtraction of two quiet NaN operand is a quiet NaN; any other result is not valid.

The C Standard says:

(C11, F.9.2 Expression transformations p1) "[...]

x − x → 0. 0 "The expressions x − x and 0. 0 are not equivalent if x is a NaN or infinite"

(where here NaN denotes a quiet NaN as per F.2.1p1 "This specification does not define the behavior of signaling NaNs. It generally uses the term NaN to denote quiet NaNs")

Since I see an answer impugning the standards compliance of Intel's compiler, and no one else has mentioned this, I will point out that both GCC and Clang have a mode in which they do something quite similar. Their default behavior is IEEE-compliant —

$ g++ -O2 test.cc && ./a.out  neg: -nan sub: nan nan nan add: nan nan div: nan nan nan mul: nan nan  $ clang++ -O2 test.cc && ./a.out  neg: -nan sub: -nan nan nan add: nan nan div: nan nan nan mul: nan nan 

— but if you ask for speed at the expense of correctness, you get what you ask for —

$ g++ -O2 -ffast-math test.cc && ./a.out  neg: -nan sub: nan nan 0.000000 add: nan nan div: nan nan 1.000000 mul: nan nan  $ clang++ -O2 -ffast-math test.cc && ./a.out  neg: -nan sub: -nan nan 0.000000 add: nan nan div: nan nan nan mul: nan nan 

I think it is entirely fair to criticize ICC's choice of default, but I would not read the entire Unix wars back into that decision.

I can give you an example which results in the same problem, but it may not give you an answer to your question. (Additionally, in this example, I'm using my Maven 3 knowledge, which may not apply for Maven 2.)

In a multi-module maven project (contains modules A and B, where B depends on A), you can add also a test dependency of A in B.

This dependency in B may look as follows:

<dependency>      <groupId>com.foo</groupId>      <artifactId>A</artifactId>      <classifier>tests</classifier>      <type>test-jar</type> <!-- I'm not sure if there is such a thing in Maven 2, but there is definitely a way to achieve such dependency in Maven 3. -->      <scope>test</scope> </dependency> 

(For more information refer to https://maven.apache.org/guides/mini/guide-attached-tests.html)

Note that project Ausually produces a secondary artifact with a classifier tests (i.e. .../com/foo/A/<version>/A-<version>-tests.jar) where the test classes and test resources are located inside.

If you build project A with -Dmaven.test.skip=true, you will get a dependency resolution error when building B unless A's test artifact is found in your local repo or remote repositories. The reason is that the test classes of A were neither compiled nor the tests artifact of A was produced.

However, if you build A with -DskipTests its tests artifact will be produced (though the tests won't run) and the dependency in B will be resolved successfully.