* 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).