[Issue 5323] std.math: struct FloatingPointControl, duplicate code and assumes X86

2022-12-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=5323

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P3

--


[Issue 5323] std.math: struct FloatingPointControl, duplicate code and assumes X86

2018-02-10 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=5323

--- Comment #6 from Iain Buclaw  ---
Has been improved somewhat by:

https://github.com/dlang/phobos/pull/4272
https://github.com/dlang/phobos/pull/5769

--


[Issue 5323] std.math: struct FloatingPointControl, duplicate code and assumes X86

2017-03-03 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=5323

Guillaume Chatelet  changed:

   What|Removed |Added

 CC||chatelet.guilla...@gmail.co
   ||m

--- Comment #5 from Guillaume Chatelet  ---
It seems to me that setting rounding mode and testing for inexact does not work
correctly on x86_64.

Correct code using the C bindings:
void main() {
import core.stdc.fenv;
fesetround(FE_UPWARD);
float x = 1.0f;
x += float.min_normal;
writefln("%.32g, inexact: %s", x, fetestexcept(FE_INEXACT) > 0);
}

> Output: 1.0011920928955078125, inexact: true

The same code using FloatingPointControl and IeeeFlags does not work at all
(neither set round nor test except)
void main() {
resetIeeeFlags();
FloatingPointControl fpctrl;
fpctrl.rounding = FloatingPointControl.roundUp;
float x = 1.0f;
x += float.min_normal;
writefln("%.32g, inexact: %s", x, ieeeFlags.inexact);
}

> Output: 1, inexact: false

Linked discussion:
http://forum.dlang.org/post/qybweycrifqgtcsse...@forum.dlang.org

--


[Issue 5323] std.math: struct FloatingPointControl, duplicate code and assumes X86

2015-11-01 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=5323

--- Comment #3 from Iain Buclaw  ---
(In reply to Infiltrator from comment #2)
> Is this still an issue?  I'd have a look at the source, but I'm afraid that
> I wouldn't be able to tell what's X86 or SPARC, etc.

Well, X86 code is guarded by a version(X86) block, SPARC code by a
version(SPARC) block.  :-)

--


[Issue 5323] std.math: struct FloatingPointControl, duplicate code and assumes X86

2015-11-01 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=5323

--- Comment #4 from Iain Buclaw  ---
Both struct FloatingPointControl and Ieeeflags still have their own private
enums.  Since these values should be mirrored somewhere in druntime stdc (it
looks like the me of five years ago couldn't work out where when searching
through the libc headers), then yes this is still a valid refactoring.

--


[Issue 5323] std.math: struct FloatingPointControl, duplicate code and assumes X86

2015-10-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=5323

Infiltrator  changed:

   What|Removed |Added

 CC||lt.infiltra...@gmail.com

--- Comment #2 from Infiltrator  ---
Is this still an issue?  I'd have a look at the source, but I'm afraid that I
wouldn't be able to tell what's X86 or SPARC, etc.

--


[Issue 5323] std.math: struct FloatingPointControl, duplicate code and assumes X86

2010-12-05 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5323



--- Comment #1 from Iain Buclaw ibuc...@ubuntu.com 2010-12-05 08:30:25 PST ---
Hmm... also found in fenv.h, so perhaps should just be importing
core.stdc.fenv (merging any bits added by std.math).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---