std.math.fmod, round, trunc are not yet pure

[dlangBugzillaToGithub]

bearophile_hugs reported this on 2013-10-21T17:43:25Z

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

CC List

• clumsycodemonkey
• s.naarmann

Description

void main() pure {
    import std.math: fmod, round, trunc;
    auto r1 = fmod(5.1, 1.5);
    auto r2 = round(5.1);
    auto r3 = trunc(5.1);
}


dmd 2.064beta2 gives:

test.d(3): Error: pure function 'D main' cannot call impure function 'std.math.fmod'
test.d(4): Error: pure function 'D main' cannot call impure function 'std.math.round'
test.d(5): Error: pure function 'D main' cannot call impure function 'std.math.trunc'

[dlangBugzillaToGithub]

clumsycodemonkey commented on 2017-01-24T02:02:21Z

I can confirm this is still an issue in 2.071.2.

[dlangBugzillaToGithub]

s.naarmann commented on 2018-10-14T14:55:49Z

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.

[dlangBugzillaToGithub]

s.naarmann commented on 2018-10-26T10:24:15Z

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.

[dlangBugzillaToGithub]

s.naarmann commented on 2018-10-26T11:48:04Z

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).

[dlangBugzillaToGithub]

s.naarmann commented on 2018-11-12T15:33:09Z

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)