<p>On Oct 23, 2013 5:21 PM, "Walter Bright" <<a href="mailto:newshound2@digitalmars.com">newshound2@digitalmars.com</a>> wrote:<br>
><br>
> On 10/23/2013 8:44 AM, Apollo Hogan wrote:<br>
>><br>
>> That is: without optimization the run-time "normalization" is correct.  With<br>
>> optimization it is broken.  That is pretty easy to work around by simply<br>
>> compiling the relevant library without optimization.  (Though it would be nice<br>
>> to have, for example, pragmas to mark some functions as "delicate" or<br>
>> "non-optimizable".)  A bigger issue is that the compile-time normalization call<br>
>> gives the 'wrong' answer consistently with or without optimization.  One would<br>
>> expect that evaluating a pure function at run-time or compile-time would give<br>
>> the same result...<br>
><br>
><br>
> 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.<br>
><br>
> This behavior is fairly deeply embedded into the front end, optimizer, and various back ends.<br>
><br>
> To precisely control maximum precision, I suggest using inline assembler to use the exact sequence of instructions needed for double-double operations.</p>
<p>Why do I feel like you recommend writing code in assembler every other post you make. :o)</p>
<p>Regards<br>
-- <br>
Iain Buclaw</p>
<p>*(p < e ? p++ : p) = (c & 0x0f) + '0';</p>