Warum funktioniert NaN - NaN == 0.0 mit dem Intel C ++ - Compiler?

Es ist bekannt, dass sich NaNs in der Arithmetik ausbreiten, aber ich konnte keine Demonstrationen finden, deshalb schrieb ich einen kleinen Test:

#include <limits>
#include <cstdio>

int main(int argc, char* argv[]) {
    float qNaN = std::numeric_limits<float>::quiet_NaN();

    float neg = -qNaN;

    float sub1 = 6.0f - qNaN;
    float sub2 = qNaN - 6.0f;
    float sub3 = qNaN - qNaN;

    float add1 = 6.0f + qNaN;
    float add2 = qNaN + qNaN;

    float div1 = 6.0f / qNaN;
    float div2 = qNaN / 6.0f;
    float div3 = qNaN / qNaN;

    float mul1 = 6.0f * qNaN;
    float mul2 = qNaN * qNaN;

    printf(
        "neg: %f\nsub: %f %f %f\nadd: %f %f\ndiv: %f %f %f\nmul: %f %f\n",
        neg, sub1,sub2,sub3, add1,add2, div1,div2,div3, mul1,mul2
    );

    return 0;
}

Das Beispiel ( hier live laufen ) liefert im Grunde das, was ich erwarten würde (das Negative ist etwas seltsam, aber es macht irgendwie Sinn):

neg: -nan
sub: nan nan nan
add: nan nan
div: nan nan nan
mul: nan nan

MSVC 2015 produziert etwas Ähnliches. Intel C ++ 15 produziert jedoch:

neg: -nan(ind)
sub: nan nan 0.000000
add: nan nan
div: nan nan nan
mul: nan nan

Speziell, qNaN - qNaN == 0.0 .

Das ... kann nicht richtig sein, oder? Was sagen die relevanten Standards (ISO C, ISO C ++, IEEE 754) dazu und warum gibt es einen Unterschied im Verhalten zwischen den Compilern?

Der Standard - Gleitkomma - Handling in Intel C ++ Compiler ist /fp:fast, die Griffe NaN‚s unsafely (die auch Ergebnisse in NaN == NaNsind truezum Beispiel). Versuchen Sie, /fp:strictoder anzugeben, /fp:preciseund prüfen Sie, ob dies hilfreich ist.

Dies . . . kann nicht richtig sein, richtig? Meine Frage: Was sagen die relevanten Normen (ISO C, ISO C ++, IEEE 754) dazu?

Petr Abdulin hat bereits geantwortet, warum der Compiler a gibt 0.0 Antwort .

Folgendes sagt IEEE-754: 2008:

(6.2 Operationen mit NaNs) "[...] Wenn für eine Operation mit leisen NaN-Eingängen außer Maximal- und Minimaloperationen ein Gleitkomma-Ergebnis geliefert werden soll, muss das Ergebnis ein leises NaN sein, das eines der folgenden sein sollte NaNs eingeben. "

Das einzig gültige Ergebnis für die Subtraktion von zwei leisen NaN-Operanden ist also ein leises NaN; Jedes andere Ergebnis ist ungültig.

Der C-Standard sagt:

(C11, F.9.2 Expressionstransformationen p1) "[...]

x - x → 0. 0 "Die Ausdrücke x - x und 0. 0 sind nicht äquivalent, wenn x ein NaN oder unendlich ist"

(wobei hier NaN ein leises NaN gemäß F.2.1p1 bezeichnet "Diese Spezifikation definiert nicht das Verhalten der Signalisierung von NaNs. Sie verwendet im Allgemeinen den Begriff NaN, um ruhige NaNs zu bezeichnen")

Da ich eine Antwort sehe, die die Einhaltung der Standards des Intel-Compilers in Frage stellt, und niemand anderes dies erwähnt hat, möchte ich darauf hinweisen, dass sowohl GCC als auch Clang einen Modus haben, in dem sie etwas ganz Ähnliches tun. Ihr Standardverhalten ist IEEE-konform -

$ 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

- aber wenn Sie auf Kosten der Korrektheit nach Geschwindigkeit fragen, bekommen Sie, wonach Sie fragen -

$ 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

Ich denke, es ist völlig fair, die Wahl des ICC als Standard zu kritisieren , aber ich würde nicht die gesamten Unix-Kriege in diese Entscheidung zurücklesen.