public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug libgcc/116017] New: libgcc/riscv/softfp: Fix loss of sign when truncating NaN values @ 2024-07-20 18:45 keithp at keithp dot com 2024-07-20 19:07 ` [Bug libgcc/116017] " pinskia at gcc dot gnu.org ` (4 more replies) 0 siblings, 5 replies; 6+ messages in thread From: keithp at keithp dot com @ 2024-07-20 18:45 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116017 Bug ID: 116017 Summary: libgcc/riscv/softfp: Fix loss of sign when truncating NaN values Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: keithp at keithp dot com Target Milestone: --- Created attachment 58714 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58714&action=edit Proposed patch Using soft float to truncate 128-bit -nan to 64-bit float loses the sign bit. When _FP_KEEP_NANFRACP is not set, the fraction *and sign* of a NaN value are discarded in _FP_PACK_SEMIRAW causing this problem. I'll note that riscv is the only target which doesn't set this value, so it could also be that the _FP_KEEPNANFRACP code is just broken? Test application: #include <stdio.h> #include <math.h> int main(void) { volatile long double ld; volatile double d; ld = (long double) NAN; ld = -ld; d = ld; printf("%a\n", d); return signbit(d) ? 0 : 1; } ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libgcc/116017] libgcc/riscv/softfp: Fix loss of sign when truncating NaN values 2024-07-20 18:45 [Bug libgcc/116017] New: libgcc/riscv/softfp: Fix loss of sign when truncating NaN values keithp at keithp dot com @ 2024-07-20 19:07 ` pinskia at gcc dot gnu.org 2024-07-20 19:31 ` pinskia at gcc dot gnu.org ` (3 subsequent siblings) 4 siblings, 0 replies; 6+ messages in thread From: pinskia at gcc dot gnu.org @ 2024-07-20 19:07 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116017 --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Note on riscv float conversion are not sign preserving for nans. That is conversions from 32bit to 64bit floats will lose the sign bit for nans. So having 128bit to/from 64bit conversions also lose the sign bit is consistent with hard floats. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libgcc/116017] libgcc/riscv/softfp: Fix loss of sign when truncating NaN values 2024-07-20 18:45 [Bug libgcc/116017] New: libgcc/riscv/softfp: Fix loss of sign when truncating NaN values keithp at keithp dot com 2024-07-20 19:07 ` [Bug libgcc/116017] " pinskia at gcc dot gnu.org @ 2024-07-20 19:31 ` pinskia at gcc dot gnu.org 2024-07-20 19:33 ` pinskia at gcc dot gnu.org ` (2 subsequent siblings) 4 siblings, 0 replies; 6+ messages in thread From: pinskia at gcc dot gnu.org @ 2024-07-20 19:31 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116017 --- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Can you test also: ``` #include <stdio.h> #include <math.h> int main(void) { volatile double d; volatile float f; d = (double) NAN; d = -d; f = d; printf("%a\n", d); // Note there is an implicit conversion to double here ... printf("%a\n", f); volatile double d1; d1 = f; printf("%a\n", d1); return signbit(d) != signbit(ld); } ``` ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libgcc/116017] libgcc/riscv/softfp: Fix loss of sign when truncating NaN values 2024-07-20 18:45 [Bug libgcc/116017] New: libgcc/riscv/softfp: Fix loss of sign when truncating NaN values keithp at keithp dot com 2024-07-20 19:07 ` [Bug libgcc/116017] " pinskia at gcc dot gnu.org 2024-07-20 19:31 ` pinskia at gcc dot gnu.org @ 2024-07-20 19:33 ` pinskia at gcc dot gnu.org 2024-07-20 19:34 ` pinskia at gcc dot gnu.org 2024-07-20 22:38 ` keithp at keithp dot com 4 siblings, 0 replies; 6+ messages in thread From: pinskia at gcc dot gnu.org @ 2024-07-20 19:33 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116017 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=113578 --- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> --- See PR 113578 , etc. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libgcc/116017] libgcc/riscv/softfp: Fix loss of sign when truncating NaN values 2024-07-20 18:45 [Bug libgcc/116017] New: libgcc/riscv/softfp: Fix loss of sign when truncating NaN values keithp at keithp dot com ` (2 preceding siblings ...) 2024-07-20 19:33 ` pinskia at gcc dot gnu.org @ 2024-07-20 19:34 ` pinskia at gcc dot gnu.org 2024-07-20 22:38 ` keithp at keithp dot com 4 siblings, 0 replies; 6+ messages in thread From: pinskia at gcc dot gnu.org @ 2024-07-20 19:34 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116017 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED See Also| |https://sourceware.org/bugz | |illa/show_bug.cgi?id=29501 Resolution|--- |INVALID --- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> --- This is by design as I mentioned to have soft-float and hard float be similar. See https://sourceware.org/bugzilla/show_bug.cgi?id=29501 also. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libgcc/116017] libgcc/riscv/softfp: Fix loss of sign when truncating NaN values 2024-07-20 18:45 [Bug libgcc/116017] New: libgcc/riscv/softfp: Fix loss of sign when truncating NaN values keithp at keithp dot com ` (3 preceding siblings ...) 2024-07-20 19:34 ` pinskia at gcc dot gnu.org @ 2024-07-20 22:38 ` keithp at keithp dot com 4 siblings, 0 replies; 6+ messages in thread From: keithp at keithp dot com @ 2024-07-20 22:38 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116017 --- Comment #5 from keithp at keithp dot com <keithp at keithp dot com> --- You're quite correct; conversion from double to float also loses the sign bit. It never occurred to me that RISC-V would be different from every other GCC target in this regard. I'll go stick a whole pile of risc-v specific code where I needs to preserve the sign; I'm glad I don't also have to preserve the significand. Yay for standards! Soft float, double, long double: test/test-nansign_rv64imac_lp64 ld: -nan (sign 1) d: nan (sign 0) f: nan (sign 0) Hard float, soft double, long double: test/test-nansign_rv64imafc_lp64f ld: -nan (sign 1) d: nan (sign 0) f: nan (sign 0) Hard float, hard double, soft long double: test/test-nansign_rv64ifd_lp64d ld: -nan (sign 1) d: nan (sign 0) f: nan (sign 0) Here's the code which generated the above: #define __STDC_WANT_IEC_60559_BFP_EXT__ #include <stdio.h> #include <math.h> #include <stdlib.h> int main(void) { volatile long double ld; volatile double d; volatile float f; int ldbit, dbit, fbit; char ldstr[64]; char dstr[64]; char fstr[64]; ld = (long double) NAN; ld = -ld; ldbit = signbit(ld); strfroml(ldstr, sizeof(ldstr), "%a", ld); d = (double) ld; dbit = signbit(d); strfromd(dstr, sizeof(dstr), "%a", d); d = (double) NAN; d = -d; f = (float) d; fbit = signbit(f); strfromf(fstr, sizeof(fstr), "%a", f); printf("ld: %s (sign %d) d: %s (sign %d) f: %s (sign %d)\n", ldstr, ldbit, dstr, dbit, fstr, fbit); if (ldbit == 0 || dbit == 0 || fbit == 0) return 1; return 0; } ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-07-20 22:38 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-07-20 18:45 [Bug libgcc/116017] New: libgcc/riscv/softfp: Fix loss of sign when truncating NaN values keithp at keithp dot com 2024-07-20 19:07 ` [Bug libgcc/116017] " pinskia at gcc dot gnu.org 2024-07-20 19:31 ` pinskia at gcc dot gnu.org 2024-07-20 19:33 ` pinskia at gcc dot gnu.org 2024-07-20 19:34 ` pinskia at gcc dot gnu.org 2024-07-20 22:38 ` keithp at keithp dot com
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).