Чому NaN - NaN == 0,0 з компілятором Intel C ++?

Добре відомо, що NaN поширюються в арифметиці, але я не міг знайти жодних демонстрацій, тому я написав невеликий тест:

#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;
}

Приклад ( запуск тут ) дає в основному те, що я очікував (негатив трохи дивний, але це має сенс):

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

MSVC 2015 виробляє щось подібне. Однак Intel C ++ 15 виробляє:

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

В Зокрема, qNaN - qNaN == 0.0.

Це ... не може бути прав, так? Що говорять про це відповідні стандарти (ISO C, ISO C ++, IEEE 754), і чому є різниця у поведінці між компіляторами?

Обробкою з плаваючою комою за замовчуванням у компіляторі Intel C ++ є /fp:fast, що обробляє NaNнебезпечно (що також призводить NaN == NaN, trueнаприклад,). Спробуйте вказати /fp:strictчи /fp:preciseі подивіться, чи це допомагає.

Це. . . не може бути прав, правда? Моє запитання: що про це говорять відповідні стандарти (ISO C, ISO C ++, IEEE 754)?

Петро Абдулін вже відповів, чому упорядник дає 0.0відповідь.

Ось що говорить IEEE-754: 2008:

(6.2. Операції з NaN) "[...] Для операцій з тихими входами NaN, крім максимальних і мінімальних операцій, якщо потрібно подати результат з плаваючою комою, результат повинен бути тихим NaN, який повинен бути одним із вхідні NaN. "

Таким чином, єдиним правильним результатом віднімання двох тихих операндів NaN є тихий NaN; будь-який інший результат недійсний.

Стандарт C говорить:

(C11, F.9.2 Перетворення виразів p1) "[...]

x - x → 0. 0 "Вирази x - x і 0. 0 не еквівалентні, якщо x - NaN або нескінченна"

(де тут NaN позначає спокійний NaN згідно з F.2.1p1 "Ця специфікація не визначає поведінку сигналізації NaN. Зазвичай він використовує термін NaN для позначення тихих NaNs")

Оскільки я бачу відповідь, що заперечує відповідність стандартам компілятора Intel, і ніхто більше не згадував про це, я зазначу, що і GCC, і Clang мають режим, в якому вони роблять щось досить схоже. Їх поведінка за замовчуванням відповідає IEEE -

$ 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

- але якщо ви попросите швидкості за рахунок правильності, ви отримаєте те, що просите -

$ 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

Я думаю, що цілком справедливо критикувати вибір ICC за замовчуванням , але я не читав би цілі війни Unix назад у цьому рішенні.