Question/request/bug(?) re. floating-point in dmd

Iain Buclaw ibuclaw at ubuntu.com
Wed Oct 30 15:36:18 PDT 2013


On Oct 23, 2013 5:21 PM, "Walter Bright" <newshound2 at digitalmars.com> wrote:
>
> On 10/23/2013 8:44 AM, Apollo Hogan wrote:
>>
>> That is: without optimization the run-time "normalization" is correct.
 With
>> optimization it is broken.  That is pretty easy to work around by simply
>> compiling the relevant library without optimization.  (Though it would
be nice
>> to have, for example, pragmas to mark some functions as "delicate" or
>> "non-optimizable".)  A bigger issue is that the compile-time
normalization call
>> gives the 'wrong' answer consistently with or without optimization.  One
would
>> expect that evaluating a pure function at run-time or compile-time would
give
>> the same result...
>
>
> A D compiler is allowed to compute floating point results at arbitrarily
large precision - the storage size (float, double, real) only specify the
minimum precision.
>
> This behavior is fairly deeply embedded into the front end, optimizer,
and various back ends.
>
> To precisely control maximum precision, I suggest using inline assembler
to use the exact sequence of instructions needed for double-double
operations.

Why do I feel like you recommend writing code in assembler every other post
you make. :o)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131030/b6a272d5/attachment.html>


More information about the Digitalmars-d mailing list