From: "Anastasios" <antonbachin@yahoo.com>
To: "Rich Felker" <dalias@libc.org>
Cc: "" <musl@lists.openwall.com>
Subject: Re: Bug report: strtod drops LSB
Date: Wed, 25 Sep 2019 13:11:03 -0500 [thread overview]
Message-ID: <78fbaffa-9dc5-4b80-b93f-98a329f0d3f6@getmailbird.com> (raw)
In-Reply-To: <ff416ebd-10f5-4e34-b1f3-e6839c6c610d@getmailbird.com>
[-- 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 --]
prev parent reply other threads:[~2019-09-25 18:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-25 14:32 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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=78fbaffa-9dc5-4b80-b93f-98a329f0d3f6@getmailbird.com \
--to=antonbachin@yahoo.com \
--cc=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).