5 ms·

Using C++ under Clang 17 and later (possibly earlier as well, I haven't checked) std::numeric_limits<T>::is_iec559 comes back as true for me for x86_64 on Debia

Using C++ under Clang 17 and later (possibly earlier as well, I haven't checked) std::numeric_limits<T>::is_iec559 comes back as true for me for x86_64 on Debian as well as when compiling for Emscripten. Might it be due to your compiler flags? Or is this somehow related to a C/C++ divergence?

eesmith 7mo ago
If I am not mistaken, is_iec559 concerns numerical representation, while __STDC_IEC_559__ is broader, and includes the behavior of numerical operations like 1.0/-0.0 and various functions. Huh. https://en.cppreference.com/w/c/23.html https://en.cppreference.com/w/c/23.html says the "Old feature-test macro" __STDC_IEC_559__ was deprecated in C23, in favor of __STDC_IEC_60559_BFP__ .
shakna 7mo ago
The standard warns that macros and assertions can return true for this one, even if it isn't actually true. The warning, because that's what compilers currently do. Its one of the caveats of the C-family that developers are supposed to be aware of, but often aren't. It doesn't support IEEE 754 fully. There is a standard to do so, but no one has actually implemented it.
- fc417fc802 7mo ago
  I don't see any such caveat mentioned here? Is the linked page incomplete? https://en.cppreference.com/w/cpp/types/numeric_limits/is_iec559.html https://en.cppreference.com/w/cpp/types/numeric_limits/is_ie... Of course in my case what I'm actually concerned with is the behavior surrounding inf and NaN. Thankfully I've never been forced to write code that relied on subtle precision or rounding differences. If it ever comes up I'd hope to keep it to a platform independent fixed point library.
  - shakna 7mo ago
    CPPReference is not the C++ standard. Its a wiki. It gets things wrong. It doesn't always give you the full information. Probably best not to rely on it, for things that matter. But, for example, LLVM does not fully support IEEE 754 [0]. And nor does GCC - who list it as unsupported, despite defining the macro and having partial support. [1] The biggest caveat is in Annex F of the C standard: > The C functions in the following table correspond to mathematical operations recommended by IEC 60559. However, correct rounding, which IEC 60559 specifies for its operations, is not required for the C functions in the table. The C++ standard [2] barely covers support, but if a type supports any of the properties of ISO 60559, then it gets is_iec559 - even if that support is _incomplete_. This paper [3] is a much deeper dive - but the current state for C++ is worse than C. Its underspecified. > When built with version 18.1.0 of the clang C++ compiler, without specifying any compiler options, the output is: > distance: 0.0999999 > proj_vector_y: -0.0799999 > Worse, if -march=skylake is passed to the clang C++ compiler, the output is: > distance: 0.1 > proj_vector_y: -0.08 [0] https://github.com/llvm/llvm-project/issues/17379 https://github.com/llvm/llvm-project/issues/17379 [1] https://www.gnu.org/software/gcc/projects/c-status.html https://www.gnu.org/software/gcc/projects/c-status.html [2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4950.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n49... [3] https://isocpp.org/files/papers/P3375R2.html https://isocpp.org/files/papers/P3375R2.html

eesmith 7mo ago

If I am not mistaken, is_iec559 concerns numerical representation, while __STDC_IEC_559__ is broader, and includes the behavior of numerical operations like 1.0/-0.0 and various functions. Huh. https://en.cppreference.com/w/c/23.html https://en.cppreference.com/w/c/23.html says the "Old feature-test macro" __STDC_IEC_559__ was deprecated in C23, in favor of __STDC_IEC_60559_BFP__ .

shakna 7mo ago

The standard warns that macros and assertions can return true for this one, even if it isn't actually true. The warning, because that's what compilers currently do. Its one of the caveats of the C-family that developers are supposed to be aware of, but often aren't. It doesn't support IEEE 754 fully. There is a standard to do so, but no one has actually implemented it.

fc417fc802 7mo ago
I don't see any such caveat mentioned here? Is the linked page incomplete? https://en.cppreference.com/w/cpp/types/numeric_limits/is_iec559.html https://en.cppreference.com/w/cpp/types/numeric_limits/is_ie... Of course in my case what I'm actually concerned with is the behavior surrounding inf and NaN. Thankfully I've never been forced to write code that relied on subtle precision or rounding differences. If it ever comes up I'd hope to keep it to a platform independent fixed point library.
- shakna 7mo ago
  CPPReference is not the C++ standard. Its a wiki. It gets things wrong. It doesn't always give you the full information. Probably best not to rely on it, for things that matter. But, for example, LLVM does not fully support IEEE 754 [0]. And nor does GCC - who list it as unsupported, despite defining the macro and having partial support. [1] The biggest caveat is in Annex F of the C standard: > The C functions in the following table correspond to mathematical operations recommended by IEC 60559. However, correct rounding, which IEC 60559 specifies for its operations, is not required for the C functions in the table. The C++ standard [2] barely covers support, but if a type supports any of the properties of ISO 60559, then it gets is_iec559 - even if that support is _incomplete_. This paper [3] is a much deeper dive - but the current state for C++ is worse than C. Its underspecified. > When built with version 18.1.0 of the clang C++ compiler, without specifying any compiler options, the output is: > distance: 0.0999999 > proj_vector_y: -0.0799999 > Worse, if -march=skylake is passed to the clang C++ compiler, the output is: > distance: 0.1 > proj_vector_y: -0.08 [0] https://github.com/llvm/llvm-project/issues/17379 https://github.com/llvm/llvm-project/issues/17379 [1] https://www.gnu.org/software/gcc/projects/c-status.html https://www.gnu.org/software/gcc/projects/c-status.html [2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4950.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n49... [3] https://isocpp.org/files/papers/P3375R2.html https://isocpp.org/files/papers/P3375R2.html