From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4790 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: printf issues Date: Fri, 4 Apr 2014 22:54:12 +0200 Message-ID: <20140404205412.GI3034@port70.net> References: <20140404141515.GD3034@port70.net> <20140404150705.GN26358@brightrain.aerifal.cx> <20140404185413.GH3034@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1396644871 11293 80.91.229.3 (4 Apr 2014 20:54:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Apr 2014 20:54:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4794-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 04 22:54:24 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 1WWB84-0006AN-OL for gllmg-musl@plane.gmane.org; Fri, 04 Apr 2014 22:54:24 +0200 Original-Received: (qmail 24539 invoked by uid 550); 4 Apr 2014 20:54:24 -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 24531 invoked from network); 4 Apr 2014 20:54:23 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4790 Archived-At: * Morten Welinder [2014-04-04 16:01:08 -0400]: > 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? to support FLT_EVAL_METHOD==2 (for i386 on gcc without sse) this means that all fp arithmetics is evaluated at long double precision on the fpu and even if we use different types or cast we have to take care of excess precision related issues (double-rounding, and various bugs in older gcc) which may or may not be easy in this case it seems to me that single precision float can be used there, we just have to make sure that the excess precision is rounded away correctly before the round+small != round comparision > 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) > yes, that is known and unfortunate limitation, it's in their manual: http://valgrind.org/docs/manual/manual-core.html#manual-core.limits we cannot do much about it: with such broken arithmetics arbitrarily bad things can happen even if we remove long doubles from the printf code