Probable bug in MSVC with compile-time NaN comparison

Question

My colleague was doing some basic experiments with NaN and was puzzled by the behavior on Visual Studio that did not match his expectations. After discussion, it seems that he uncovered a probable compiler bug in MSVC 2019.

This code snippet fails to compile on MSVC, but is fine on Clang and GCC:

#include <limits>

int main()
{
    static_assert(!(1 < std::numeric_limits<double>::quiet_NaN()), "compiler bug?");
}

Demo: https://godbolt.org/z/xGdqd5

Il seems that the problem concerns compile-time comparison of a constant with std::numeric_limits<double>::quiet_NaN(), something not really useful in real life.

The comparison > and < is always false if quiet_NaN is compared with a variable as expected by IEEE-754.

Meridethmeridian

what makes you certain that this is a compiler bug? – Denim

I think you should check std::numeric_limits<double>::has_quiet_NaN == true before, though for msvc it seems to hold – Denim

Possibly relevant: NaN comparison rule in C/C++. – Menderes

The odd thing is that MSVC outputs false for the following: std::cout << std::boolalpha << (1 < std::numeric_limits<double>::quiet_NaN()) << std::endl;. So it looks like a bug. – Menderes

@largest_prime_is_463035818 I am not certain, this is why I asked. I thought C++ would constrain IEE-754, but from Adrian Mode comment, this does not seem to be in the standard. – Meridethmeridian

@AdrianMole Your linked question explains that there is no requirement that any comparison against NaN is false. So why would it be a bug? – Mastoid

@Mastoid Just seems odd to me that a run-time comparison between two 'constants' should differ from a compile-time comparison. But, as you say, the Standard places no constraint. – Menderes

I agree that this is a compiler bug, since it continues to occur under /fp:strict where, even though the Standard does not require it, Microsoft claims strict adherence. – Beaner