[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 Edwin Lu changed: What|Removed |Added CC||ewlu at rivosinc dot com --- Comment #12 from Edwin Lu --- (In reply to Jonathan Wakely from comment #11) > Patch posted: > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659187.html Hi Jonathan our precommit ci is catching build issues coming from this patch when building with both glibc and newlib https://github.com/ewlu/gcc-precommit-ci/issues/1991 /data-disk-1/github/rise-gcc-ci-precommit-8/_work/gcc-precommit-ci/gcc-precommit-ci/riscv-gnu-toolchain/build/build-gcc-newlib-stage2/riscv64-unknown-elf/libstdc++-v3/include/ostream:488:58: error: '__builtin_bit_cast' source size '4' not equal to destination type size '2' 488 | __sign = static_cast<_To>(__builtin_bit_cast(short, __f)); | ^ /data-disk-1/github/rise-gcc-ci-precommit-8/_work/gcc-precommit-ci/gcc-precommit-ci/riscv-gnu-toolchain/build/build-gcc-newlib-stage2/riscv64-unknown-elf/libstdc++-v3/include/ostream:492:58: error: '__builtin_bit_cast' source size '4' not equal to destination type size '8' 492 | __sign = static_cast<_To>(__builtin_bit_cast(long long, __f)); | ^~~~ make[6]: *** [Makefile:658: complex_io.lo] Error 1
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #11 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659187.html
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-05-15 Resolution|INVALID |--- Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #10 from Jonathan Wakely --- I'm reopening this to deal with it as a libstdc++ bug, because LWG seems to support changing the standard so that this Just Works. https://cplusplus.github.io/LWG/issue4101
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
--- Comment #9 from Andrew Waterman ---
For my M1 running Ventura 13.6, NaN payloads _are_ propagated, sign bit
included. This test prints fffc0080:
int main()
{
volatile long long ll = 0x8010;
volatile double d;
memcpy((char*)&d, (char*)&ll, sizeof(ll));
volatile float f = d;
volatile int i;
memcpy((char*)&i, (char*)&f, sizeof(i));
printf("%x\n", i);
return 0;
}
So perhaps Apple has switched from default-NaN mode to NaN-propagating mode in
the time since that R blog post was written.
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 --- Comment #8 from Jonathan Wakely --- Hmm, you could be right. It looks like the printf in Apple libc doesn't print "-nan" even when not converting from float to double. According to https://developer.r-project.org/Blog/content/post/2020-11-02-apple-silicon.html the Apple silicon NaN payloads are not propagated by default, but I don't know if that means the signbit is not propagated. I assumed it meant they were running in default NaN mode.
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 Andrew Waterman changed: What|Removed |Added CC||andrew at sifive dot com --- Comment #7 from Andrew Waterman --- In the case of the M1, I don't think the problem is that the sign bit isn't making it to printf; I think printf is choosing not to print the sign. The ARMv8 fcvt instruction preserves the sign bit when converting NaNs (unless the processor is in default-NaN mode, which Mac OS does not seem to use).
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 --- Comment #6 from Jonathan Wakely --- (In reply to Joseph S. Myers from comment #2) > If a conversion from float to double (for passing in variable arguments) > occurs at runtime on RISC-V, that will produce a positive-signed NaN (that's > what the RISC-V floating-point instructions do). Cf. > https://sourceware.org/bugzilla/show_bug.cgi?id=29501 (for strfrom > functions). This seems to happen on Apple M1 chips too.
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
--- Comment #5 from Jonathan Wakely ---
Maybe we could make it work for std::ostream with something like:
--- a/libstdc++-v3/include/std/ostream
+++ b/libstdc++-v3/include/std/ostream
@@ -233,7 +233,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 117. basic_ostream uses nonexistent num_put member functions.
+#ifdef __riscv
+ return _M_insert(__builtin_copysign((double)__f,
+ (double)-!!__builtin_signbit(__f));
+#else
return _M_insert(static_cast(__f));
+#endif
}
__ostream_type&
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jonathan Wakely --- So the reason the sign isn't lost for -O1 is that the conversion to double happens at compile-time and a negative nan is compiled into the executable, rather than being converted by the processor at runtime. Huh, OK. I guess Matthias can close his Debian bug then.
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 --- Comment #3 from Andrew Pinski --- and since __builtin_printf is variadic function, floats are promoted to double causing the removal of the payload of NaN on RISCV at runtime ...
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 --- Comment #2 from Joseph S. Myers --- If a conversion from float to double (for passing in variable arguments) occurs at runtime on RISC-V, that will produce a positive-signed NaN (that's what the RISC-V floating-point instructions do). Cf. https://sourceware.org/bugzilla/show_bug.cgi?id=29501 (for strfrom functions).
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 Jonathan Wakely changed: What|Removed |Added Summary|Incorrect signbit for -nan |Incorrect sign printed for |on RISC-V |-nan on RISC-V --- Comment #1 from Jonathan Wakely --- It could also be a glibc bug for RISC-V of course.
