* Bug report: strtod drops LSB @ 2019-09-25 14:32 Anastasios 2019-09-25 15:06 ` Szabolcs Nagy 2019-09-25 15:51 ` Rich Felker 0 siblings, 2 replies; 5+ messages in thread From: Anastasios @ 2019-09-25 14:32 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 687 bytes --] Hello, Consider this program, strtod.c: #include <stdlib.h> #include <stdio.h> int main() { printf("%lf\n", strtod("283686952306183", NULL)); } With current musl master from Git: $ musl-gcc -static strtod.c -o a.musl $ ./a.musl 283686952306176.000000 By comparison, with glibc: $ gcc -static strtod.c -o a.glibc $ ./a.glibc 283686952306183.000000 The correct binary representation of this float is 0x42f0203040506070 but musl strtod produces 0x42f0203040506000 i.e., it fails to set the LSB. I examined this while ruling out printf as the cause. [-- Attachment #2: Type: text/html, Size: 1670 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug report: strtod drops LSB 2019-09-25 14:32 Bug report: strtod drops LSB Anastasios @ 2019-09-25 15:06 ` Szabolcs Nagy 2019-09-25 15:51 ` Rich Felker 1 sibling, 0 replies; 5+ messages in thread From: Szabolcs Nagy @ 2019-09-25 15:06 UTC (permalink / raw) To: musl * Anastasios <antonbachin@yahoo.com> [2019-09-25 09:32:35 -0500]: > Hello, > > Consider this program, strtod.c: > > #include <stdlib.h> > #include <stdio.h> > > int main() > { > printf("%lf\n", strtod("283686952306183", NULL)); > } > > With current musl master from Git: > > $ musl-gcc -static strtod.c -o a.musl > $ ./a.musl > 283686952306176.000000 > > By comparison, with glibc: > > $ gcc -static strtod.c -o a.glibc > $ ./a.glibc > 283686952306183.000000 > works for me on both i486-linux-musl and aarch64-linux-musl. i have no idea what can cause such bug. can you try printf with %a and strtod(...)==0x1.020304050607p+48 to see if it's printf %lf that goes wrong? > The correct binary representation of this float is > > 0x42f0203040506070 > > but musl strtod produces > > 0x42f0203040506000 > > i.e., it fails to set the LSB. I examined this while ruling out printf as the cause. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug report: strtod drops LSB 2019-09-25 14:32 Bug report: strtod drops LSB Anastasios 2019-09-25 15:06 ` Szabolcs Nagy @ 2019-09-25 15:51 ` Rich Felker 2019-09-25 17:56 ` Anastasios 1 sibling, 1 reply; 5+ messages in thread From: Rich Felker @ 2019-09-25 15:51 UTC (permalink / raw) To: Anastasios; +Cc: musl On Wed, Sep 25, 2019 at 09:32:35AM -0500, Anastasios wrote: > Hello, > > Consider this program, strtod.c: > > #include <stdlib.h> > #include <stdio.h> > > int main() > { > printf("%lf\n", strtod("283686952306183", NULL)); > } > > With current musl master from Git: > > $ musl-gcc -static strtod.c -o a.musl > $ ./a.musl > 283686952306176.000000 > > By comparison, with glibc: > > $ gcc -static strtod.c -o a.glibc > $ ./a.glibc > 283686952306183.000000 > > The correct binary representation of this float is > > 0x42f0203040506070 > > but musl strtod produces > > 0x42f0203040506000 > > i.e., it fails to set the LSB. I examined this while ruling out printf as the cause. I can't reproduce this. My test program for strtod shows, for the input "283686952306183": d: 283686952306183 [0x1.020304050607p+48] [42f0203040506070] I suspect you miscompiled musl, possibly by passing in CFLAGS (perhaps from defaults in your environment?) that break floating point semantics. We test for and refuse to build if __FAST_MATH__ is defined, but GCC only defines it if you use -ffast-math, not if you manually enable one or more of the individual broken options that -ffast-math enables. Alternatively, it's possible that you have a broken compiler version that miscompiles floating point code. Rich ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug report: strtod drops LSB 2019-09-25 15:51 ` Rich Felker @ 2019-09-25 17:56 ` Anastasios 2019-09-25 18:11 ` Anastasios 0 siblings, 1 reply; 5+ messages in thread From: Anastasios @ 2019-09-25 17:56 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 1737 bytes --] Having looked into it more, I found this is due to being on WSL, and it is a duplicate of https://github.com/microsoft/WSL/issues/830 [https://github.com/microsoft/WSL/issues/830], which, I see, you are already well aware of. Please excuse the noise. On 9/25/2019 10:51:53 AM, Rich Felker <dalias@libc.org> wrote: On Wed, Sep 25, 2019 at 09:32:35AM -0500, Anastasios wrote: > Hello, > > Consider this program, strtod.c: > > #include > #include > > int main() > { > printf("%lf\n", strtod("283686952306183", NULL)); > } > > With current musl master from Git: > > $ musl-gcc -static strtod.c -o a.musl > $ ./a.musl > 283686952306176.000000 > > By comparison, with glibc: > > $ gcc -static strtod.c -o a.glibc > $ ./a.glibc > 283686952306183.000000 > > The correct binary representation of this float is > > 0x42f0203040506070 > > but musl strtod produces > > 0x42f0203040506000 > > i.e., it fails to set the LSB. I examined this while ruling out printf as the cause. I can't reproduce this. My test program for strtod shows, for the input "283686952306183": d: 283686952306183 [0x1.020304050607p+48] [42f0203040506070] I suspect you miscompiled musl, possibly by passing in CFLAGS (perhaps from defaults in your environment?) that break floating point semantics. We test for and refuse to build if __FAST_MATH__ is defined, but GCC only defines it if you use -ffast-math, not if you manually enable one or more of the individual broken options that -ffast-math enables. Alternatively, it's possible that you have a broken compiler version that miscompiles floating point code. Rich [-- Attachment #2: Type: text/html, Size: 2679 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug report: strtod drops LSB 2019-09-25 17:56 ` Anastasios @ 2019-09-25 18:11 ` Anastasios 0 siblings, 0 replies; 5+ messages in thread From: Anastasios @ 2019-09-25 18:11 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 2207 bytes --] For the record, this is the program I used to confirm that it's a duplicate: #include <stdlib.h> #include <stdio.h> void main() { unsigned short control_word = 0x37f; asm ("fldcw %0" : : "m" (control_word)); printf("%lf\n", strtod("283686952306183", NULL)); } Perhaps it can help if anyone on WSL reports this again. On 9/25/2019 12:56:35 PM, Anastasios <antonbachin@yahoo.com> wrote: Having looked into it more, I found this is due to being on WSL, and it is a duplicate of https://github.com/microsoft/WSL/issues/830 [https://github.com/microsoft/WSL/issues/830], which, I see, you are already well aware of. Please excuse the noise. On 9/25/2019 10:51:53 AM, Rich Felker <dalias@libc.org> wrote: On Wed, Sep 25, 2019 at 09:32:35AM -0500, Anastasios wrote: > Hello, > > Consider this program, strtod.c: > > #include > #include > > int main() > { > printf("%lf\n", strtod("283686952306183", NULL)); > } > > With current musl master from Git: > > $ musl-gcc -static strtod.c -o a.musl > $ ./a.musl > 283686952306176.000000 > > By comparison, with glibc: > > $ gcc -static strtod.c -o a.glibc > $ ./a.glibc > 283686952306183.000000 > > The correct binary representation of this float is > > 0x42f0203040506070 > > but musl strtod produces > > 0x42f0203040506000 > > i.e., it fails to set the LSB. I examined this while ruling out printf as the cause. I can't reproduce this. My test program for strtod shows, for the input "283686952306183": d: 283686952306183 [0x1.020304050607p+48] [42f0203040506070] I suspect you miscompiled musl, possibly by passing in CFLAGS (perhaps from defaults in your environment?) that break floating point semantics. We test for and refuse to build if __FAST_MATH__ is defined, but GCC only defines it if you use -ffast-math, not if you manually enable one or more of the individual broken options that -ffast-math enables. Alternatively, it's possible that you have a broken compiler version that miscompiles floating point code. Rich [-- Attachment #2: Type: text/html, Size: 4835 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-09-25 18:11 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-25 14:32 Bug report: strtod drops LSB Anastasios 2019-09-25 15:06 ` Szabolcs Nagy 2019-09-25 15:51 ` Rich Felker 2019-09-25 17:56 ` Anastasios 2019-09-25 18:11 ` Anastasios
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ 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 NNTP newsgroup(s).