ICC does not seem to do anything with the argument of `__builtin_nan(...)`. While this seems to be allowed by the standard (it is a compiler intrinsic, after all, and anyway the `std::nan(...)` function it is based upon is "implementation-defined"), it doesn't seem very useful.
For example, consider the problem of creating a `float` whose bitwise representation is all `1`s (useful for e.g. low-level SSE programming). This works out to be a kind of NaN, so you can't write it directly. If you want it to be `constexpr`, you can't use `memcpy(...)` (the only correct way to do type punning (pre-C++20 `std::bit_cast<...>(...)`, which currently no compiler supports yet)) either. Using `__builtin_nanf(...)`, which under GCC/Clang/MSVC semantics takes the argument as the returned NaN's mantissa, we can write the function:
constexpr inline float get_bits1s() {
return -__builtin_nanf("0x7FFFFF");
}
However, ICC produces `0xFFC00000` (i.e. the negative of `0x7FC00000`, the simplest-possible quiet-NaN). I haven't been able to get anything besides those two values out of ICC, nor documentation about how that intrinsic is supposed to work.
Suggestion: make ICC do something useful with the argument of `__builtin_nan(...)`, and document it.
