Closed dneto0 closed 2 months ago
I encountered this on an Apple Silicon mac with a recent Xcode.
I also replicated it on an x86-64 Linux machine with Clang, but not GCC.
Here's a short and messy program that shows what's going on:
#include <iostream>
#include <cstring>
#include <iomanip>
int main() {
const float neg_inf = -1.0f/0.0f;
const float nan = neg_inf * 0.0f;
std::cout << " neg_inf " << neg_inf << std::endl;
std::cout << " nan " << nan << std::endl;
int i0;
int i1;
std::memcpy(&i0, &neg_inf, 4);
std::memcpy(&i1, &nan, 4);
std::cout << " i0 " << std::hex << i0 << std::endl;
std::cout << " i1 " << std::hex << i1 << std::endl;
}
$ g++ -std=c++11 x.cpp -o x
$ ./x
neg_inf -inf
nan -nan
i0 ff800000
i1 ffc00000
$ clang++ -std=c++11 x.cpp -o x
$ ./x
neg_inf -inf
nan nan
i0 ff800000
i1 7fc00000
This is GCC 13.2.0, Clang 16.
Test/hlsl.inf.vert tests parsing and some constant math on infinities, including (-1.#INF * 0.0). By IEEE 754 rules, that result is a NaN, but its sign is not significant. The test output assumes a negative-NaN is in the generated SPIR-V.
However, the math library on some platforms (like macOS 14, a.k.a. Sonoma) will produce a positive NaN instead.
This PR adjusts the test so it takes the absolute value of the NaN, to ensure we the emitted SPIR-V has the NaN with a 0 for it sign bit.