std::sqrt(-1.0) == 0.0 evaluates to true!

[Eirik]

std::sqrt(-1.0) == 0.0 evaluates to true with optimization level O1 using oneAPI 2021.3 on Windows. Is this a bug?

My understanding is that according to IEC559 NaNs should not be equal to anything, noth even themselves. In debug (Od) the comparison is false as expected.

I stumbled upon this problem while upgrading my application from Intel C++ Compiler 19.0 to oneAPI 2021.3. I have not seen this behavoiur in any earlier version of the Intel C++ compiler or any other compiler (MSVC, Clang, GCC). The linux version of the intel compiler seems to work as expected. 

The following sample shows the problem:

#include <cassert>
#include <cmath>
#include <iostream>
#include <limits>

int main() {
    static_assert(std::numeric_limits<double>::is_iec559, "");

    const double sqrt = std::sqrt(-1.0);
    const double div0 = 0.0 / 0.0;

    std::cout << "sqrt " << sqrt << '\n';
    std::cout << "div0 " << div0 << '\n';

    assert(std::isnan(sqrt));
    assert(std::isnan(div0));

    std::cout << std::boolalpha;

    std::cout << "sqrt == 0.0: " << (sqrt == 0.0) << '\n';
    std::cout << "div0 == 0.0: " << (div0 == 0.0) << '\n';

    std::cout << "sqrt == sqrt: " << (sqrt == sqrt) << '\n';
    std::cout << "div0 == div0: " << (div0 == div0) << '\n';
}

 Compiling and running with /Od and /O1 I get the following output:

C:\test>icx /Od main.cpp && main.exe
Intel(R) oneAPI DPC++/C++ Compiler for applications running on Intel(R) 64, Version 2021.3.0 Build 20210619
Copyright (C) 1985-2021 Intel Corporation. All rights reserved.

sqrt -nan(ind)
div0 nan
sqrt == 0.0: false
div0 == 0.0: false
sqrt == sqrt: false
div0 == div0: false

C:\test>icx /O1 main.cpp && main.exe
Intel(R) oneAPI DPC++/C++ Compiler for applications running on Intel(R) 64, Version 2021.3.0 Build 20210619
Copyright (C) 1985-2021 Intel Corporation. All rights reserved.

sqrt -nan(ind)
div0 nan
sqrt == 0.0: true
div0 == 0.0: false
sqrt == sqrt: true
div0 == div0: false

 It seems to be a problem with -NaN. Is this a bug in the compiler? Is there some way to prevent it from happening? 

[Eirik]

After some more investigation I see that using floating point model precise (/fp:precise) "solves" the issue. As I understand NaNs are not required to behave properly with fp:fast.

I have never had problems with this earlier using fp:fast, so it's a bit disappointing to move to precise now, but I guess thats the price to pay for relying on undefined behaviour.

[VidyalathaB_Intel · Accepted solution]

Hi,

Thanks for reaching out to us.

>> I see that using floating point model precise (/fp:precise) "solves" the issue.

Glad to know that you have figured it out.

/fp:precise - This option tells the compiler to disable the optimizations, hence using this we get correct results.

/fp:fast - This option performs more optimizations to increase the speed of computations which may effect the accuracy of the results.

You can refer the below link for more details.

https://software.intel.com/content/www/us/en/develop/documentation/oneapi-dpcpp-cpp-compiler-dev-guide-and-reference/top/compiler-reference/compiler-options/compiler-option-details/floating-point-options/fp-model-fp.html

Please let us know if you have any other queries regarding this.

Regards,

Vidya.

[VidyalathaB_Intel]

Hi,

Thanks for accepting our solution!

As this issue has been resolved, we will no longer respond to this thread. 

If you require any additional assistance from Intel, please start a new thread. 

Any further interaction in this thread will be considered community only. 

Have a Good day.

Regards,

Vidya.