[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Apr 2014 22:08:47 -0400
From: Morten Welinder <mwelinder@...il.com>
To: musl@...ts.openwall.com
Subject: Re: printf issues
> [...] 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 <dalias@...ifal.cx> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
