7

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.

phuclv
  • 37,963
  • 15
  • 156
  • 475
prapin
  • 6,395
  • 5
  • 26
  • 44
  • what makes you certain that this is a compiler bug? – 463035818_is_not_an_ai Mar 01 '21 at 10:10
  • I think you should check `std::numeric_limits::has_quiet_NaN == true` before, though for msvc it seems to hold – 463035818_is_not_an_ai Mar 01 '21 at 10:14
  • 2
    Possibly relevant: [NaN comparison rule in C/C++](https://stackoverflow.com/q/38798791/10871073). – Adrian Mole Mar 01 '21 at 10:20
  • The odd thing is that MSVC outputs `false` for the following: `std::cout << std::boolalpha << (1 < std::numeric_limits::quiet_NaN()) << std::endl;`. So it *looks* like a bug. – Adrian Mole Mar 01 '21 at 10:24
  • 1
    @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. – prapin Mar 01 '21 at 10:27
  • @AdrianMole Your linked question explains that there is no requirement that any comparison against NaN is `false`. So why would it be a bug? – rustyx Mar 01 '21 at 10:36
  • @rustyx 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. – Adrian Mole Mar 01 '21 at 10:44
  • 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. – Ben Voigt Mar 18 '21 at 16:14

0 Answers0