[Issue 11320] std.math.fmod, round, trunc are not yet pure

[d-bugmail--- via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P4

--

[Issue 11320] std.math.fmod, round, trunc are not yet pure

[d-bugmail--- via Digitalmars-d-bugs]

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

Simon Naarmann  changed:

   What|Removed |Added

   Hardware|x86 |All
   Assignee|eiderd...@gmail.com |nob...@puremagic.com
 OS|Windows |All

--- Comment #5 from Simon Naarmann  ---
Sorry, I lack the time these weeks. I've unassigned myself.

Here are my ideas:

- Refactor setControlState into a string mixin (seems best w.r.t. spec?)
- Refactor setControlState into standalone pure function (weird because it's
impure)
- Cast round() to pure inside Phobos even though we call setCountrolState
(feels like a bad idea)

--

[Issue 11320] std.math.fmod, round, trunc are not yet pure

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from Simon Naarmann  ---
D language spec, Pure Functions:

https://dlang.org/spec/function.html#pure-functions

In Point 8, it says: As a concession to practicality, a pure function can also:
* read and write the floating point exception flags
* read and write the floating point mode flags, as long as those flags are
restored to their initial state upon function entry

That's exactly what happens in round(), but through indirection. The compiler
will not know that setControlState will be called a second time, and the
compiler will not know that setControlState enjoys the special concession of
the spec (it looks like any other impure function to the compiler).

--

[Issue 11320] std.math.fmod, round, trunc are not yet pure

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from Simon Naarmann  ---
I see no problems to making fmod() pure.

But with round(), here's the Phobos code:

auto round(real x) @trusted nothrow @nogc
{
version (CRuntime_Microsoft)
{
auto old = FloatingPointControl.getControlState();
FloatingPointControl.setControlState(
(old & (-1 - FloatingPointControl.roundingMask))
| FloatingPointControl.roundToZero
);
x = rint((x >= 0) ? x + 0.5 : x - 0.5);
FloatingPointControl.setControlState(old);
return x;
}
else
return core.stdc.math.roundl(x);
}

Can the CRuntime_Microsoft version ever be pure? It backs up global state of
the CPU's floating point processing, then restores it:

static void setControlState(ControlState newState) @trusted
{
version (InlineAsm_X86_Any)
{
asm nothrow @nogc
{
fclex;
fldcw newState;
}
// Also update MXCSR, SSE's control register.
// ...
asm nothrow @nogc { ldmxcsr mxcsr; }
// ...

How should this be handled w.r.t. purity? I haven't looked at all into how such
CPU state behaves with multithreaded code. For now, I'd have to leave round()
as impure across all platforms.

--

[Issue 11320] std.math.fmod, round, trunc are not yet pure

[d-bugmail--- via Digitalmars-d-bugs]

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

Simon Naarmann  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|eiderd...@gmail.com

--

[Issue 11320] std.math.fmod, round, trunc are not yet pure

[d-bugmail--- via Digitalmars-d-bugs]

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

Simon Naarmann  changed:

   What|Removed |Added

 CC||eiderd...@gmail.com

--- Comment #2 from Simon Naarmann  ---
This issue is still in 2.082.0.

Are there technical problems (floating representation etc.) that require
impurity? Otherwise, I'll make a PR that adds the pure keyword.

--

[Issue 11320] std.math.fmod, round, trunc are not yet pure

[via Digitalmars-d-bugs]

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

Ryan  changed:

   What|Removed |Added

 CC||clumsycodemon...@gmail.com

--- Comment #1 from Ryan  ---
I can confirm this is still an issue in 2.071.2.

--