https://issues.dlang.org/show_bug.cgi?id=13474
--- Comment #17 from Илья Ярошенко <[email protected]> --- (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. --
