[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