[Issue 13474] Discard excess precision when returning double in x87 register

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Sun Feb 15 22:23:17 PST 2015


https://issues.dlang.org/show_bug.cgi?id=13474

--- Comment #17 from Илья Ярошенко <ilyayaroshenko at gmail.com> ---
(In reply to yebblies from comment #15)

Why you have changed the name of this issue?
Bug is not only for return. Truncation should be during all calculations.

> I've thought about it some more, and I don't think this is behaving
> incorrectly given what D does specify about floating point behaviour.

Yes. D is unique language in this question. 
In other other words D is not a system language because it can't compile
correctly IEEE 754 standard.

I am disappointed.
All D contributors explain me that "it is a feature for precise math".
But this feature prohibits price math:
https://github.com/D-Programming-Language/phobos/pull/2513.

> 1. Nothing in any ABI I can find specifies that return values must be
> truncated.  (gcc does have a -ffloat-store flag)
>
> 2. D allows floating point intermediates to be at a higher precision than
> the operand types.  This doesn't explicitly include return values, but...
> 
> 3. D allows inlining, which means even if return values are explicitly
> excluded from (2) then it still can't be relied upon.
> 
> So, I conclude that calculating and returning floating point values at a
> higher precision than specified is allowed in D.
> 
> The code where you hit the problem can be fixed by:
> 
> 1. Fixing the tests to not rely on maximum precision.

The problem is that value isn't "more price". The value is wrong because
truncation should be performed during ALL calculation.

> 2. Using a wrapper on function calls where precision must be forced. (An
> intrinsic to force precision loss has been discussed in the past)

It should be performed during all std.numeric.summation ;(

> 3. Lobbying Walter for a language change enforcing this in some way.

Can you help me to do it?

> I've changed the platform as this behaviour is possible on other platforms
> too even if the current code generator never hits those cases.

--


More information about the Digitalmars-d-bugs mailing list