From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4803 Path: news.gmane.org!not-for-mail From: Morten Welinder Newsgroups: gmane.linux.lib.musl.general Subject: Re: printf issues Date: Fri, 4 Apr 2014 22:08:47 -0400 Message-ID: References: <20140404141515.GD3034@port70.net> <20140404150705.GN26358@brightrain.aerifal.cx> <20140404185413.GH3034@port70.net> <20140404210207.GR26358@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1396663748 5989 80.91.229.3 (5 Apr 2014 02:09:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Apr 2014 02:09:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4807-gllmg-musl=m.gmane.org@lists.openwall.com Sat Apr 05 04:09:03 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WWG2V-0007eC-SJ for gllmg-musl@plane.gmane.org; Sat, 05 Apr 2014 04:08:59 +0200 Original-Received: (qmail 1565 invoked by uid 550); 5 Apr 2014 02:08:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1557 invoked from network); 5 Apr 2014 02:08:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XWV7qRfOaDoC6gv6HuWLYRrFGrRzM9KC2CzIp/PAds4=; b=FdUDEGNcWqxgXZv42UuefkhS/KA5vE9m7pLAxkbq2hHMFetMxBWQLSfWOEgkLDvQH/ 5bnao9YnHUBaCSt8NWkK3L03yJ1qiWsWZKuonaNhLATeZm75H4IJ4VdGMCL5JBsD7pOJ VvzAs1HDUMVZdM12wUNTJUxERmSDe5Z44RT7929kHvEICfsXjvQWNlHtECz1v6pGgJmc FhJ+3LNa+X3FxjBy6D5S/gMwqVPjLg8HTLrWev6PXIleG2Wz4QEvQ4w0TOFAqwMRSJhh AaLHoCsx8zFKhgzkNxPSWf48PQIadkrJqtm6SFQefoZ/3FCFLr+Jhj0+dlT4QbzqH1+t A2uA== X-Received: by 10.180.211.207 with SMTP id ne15mr8599468wic.31.1396663727147; Fri, 04 Apr 2014 19:08:47 -0700 (PDT) In-Reply-To: <20140404210207.GR26358@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:4803 Archived-At: > [...] excess precision (FLT_EVAL_METHOD==2). This is why > musl uses long double internally everywhere that rounding semantics > matter. That's what I thought, but it's not actually what I see over in src/math/. If I look in src/math/floor.c I see an explicit cast from double to double used to get rid of excess precision. The similar thing ought to work in fmt_fp. Morten On Fri, Apr 4, 2014 at 5:02 PM, Rich Felker wrote: > On Fri, Apr 04, 2014 at 04:01:08PM -0400, Morten Welinder wrote: >> In fmt_fmt, the rounding decision is done using this test: >> >> /* Decide whether to round by probing round+small */ >> if (round+small != round) { ... >> >> Why is this done with long double? >> >> The reason I ask is that the Valgrind situation improves a lot if >> this is done with doubles. >> >> (Valgrind situation: Valgrind emulates long doubles, poorly, by using >> simple doubles. See, for example, https://bugs.kde.org/show_bug.cgi?id=164298) > > This is a known issue that needs to be fixed in valgrind. It's > impossible to do anything useful with rounding on x86 with types other > than double, due to excess precision (FLT_EVAL_METHOD==2). This is why > musl uses long double internally everywhere that rounding semantics > matter. > > Rich