-
-
Notifications
You must be signed in to change notification settings - Fork 705
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix issue 17243 - std.math.{FloatingPointControl,ieeeFlags} don't work on x86_64 #5240
Conversation
|
1884212
to
624b23f
Compare
9b53aed
to
0cc2e2d
Compare
|
It's my understanding that the issue can also manifest on 32-bit x86s when the compiler is configured to emit SSE instructions (not sure if that can be done with dmd).There doesn't seem to be a The failures of the doc tester and CircleCI don't make sense to me. The doc tester says:
And CircleCI says:
Both seem unrelated. |
bb53e70
to
3536c56
Compare
On x86, even if for rounding DMD emitts code for the FPU one may use the std.math API and write custom asm SSE code that relies on it, hence both FPU and SSE flags should be set. (IMO, this can be discussed) |
d1aebd5
to
1bf8837
Compare
I've added a fallback to CPUID for x86. From my end, this is good to go. I've fixed the test failures and squashed the fixup commits. auto-tester is green (pending testing of the fallback mentioned above). |
| @@ -155,6 +155,18 @@ else version(D_InlineAsm_X86_64) | |||
| version = InlineAsm_X86_Any; | |||
| } | |||
|
|
|||
| version (X86_64) version = StaticallyHaveSSE; | |||
| version (X86) version (OSX) version = StaticallyHaveSSE; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this is correct. Does OSX require SSE? This is here, because I've noticed that dmd emits SSE code for 32-bit OSX.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's b/c Apple only ever sold x86_64 CPUs.
std/math.d
Outdated
| INVALID_MASK = 0x01 | ||
| } | ||
| // Don't bother about subnormals, they are not supported on most CPUs. | ||
| // SUBNORMAL_MASK = 0x02; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment seemed bogus. My run-of-the-mill AMD CPU and the auto-tester ones apparently support it.
std/math.d
Outdated
| @@ -4531,6 +4538,10 @@ public: | |||
| /// A machine NaN was generated. (example: x = real.infinity * 0.0; ) | |||
| @property bool invalid() { return (flags & INVALID_MASK) != 0; } | |||
|
|
|||
| /** A subnormal number was used in a calculation. | |||
| (example: x = real.min_normal / 2 + 1) */ | |||
| @property bool subnormal() { return (flags & SUBNORMAL_MASK) != 0; } | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andralex: Adding a new method here. As far as I remember, you want to review new names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm cool, please make const and so the others
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please make const and so the others
Made this one const. New PR for the others as it's independent from this PR: #5246
| fclex; | ||
| fldcw 8[RSP]; | ||
| ret; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This deleted code looks very clever. Unfortunately, there is no comment on what it achieves. The generic variant below seems to work just fine on Win64, and it's much simpler. So I'm tearing down this fence without knowing why it was put up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was just the naked version of the asm block below, no need for that here.
f7d16c4
to
0ecb8d7
Compare
Of course it went red then. Fixed getIeeeFlags and resetIeeeFlags. All green again. |
std/math.d
Outdated
| @@ -4531,6 +4545,10 @@ public: | |||
| /// A machine NaN was generated. (example: x = real.infinity * 0.0; ) | |||
| @property bool invalid() { return (flags & INVALID_MASK) != 0; } | |||
|
|
|||
| /** A subnormal number was used in a calculation. | |||
| (example: x = real.min_normal / 2 + 1) */ | |||
| @property bool subnormal() const { return (flags & SUBNORMAL_MASK) != 0; } | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The majority of targets don't have an exception for denormals, I don't think this should be added here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The majority of targets don't have an exception for denormals, I don't think this should be added here.
As far as I see, IeeeFlags only works on x86 and x86-64 at the moment. Everything else errors out with "not yet supported". x86(-64) are the ones that have this, right? Would it be ok if this was versioned away from the others?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I see, IeeeFlags only works on x86 and x86-64 at the moment. Everything else errors out with "not yet supported"
GDC has code for ARM as well: https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/src/std/math.d#L4372 and LDC probably supports even more targets. The part of the code that has never been upstreamed is mostly GDC extended ASM so it's not useful for other compilers anyway.
We unfortunately don't have any guidelines yet how to deal with architecture specific features (there's a similar problem for cpuid). I guess we could add this function but we should at least make sure to explicitly document it as non-portable.
85eb329
to
f173c72
Compare
|
I've removed the new I've also squashed everything into one commit. The commit list was becoming messy. |
f173c72
to
09679c2
Compare
I'm far from being an expert on this stuff. I learned about the different control registers only when investigating this issue here. If someone more experienced wants to take over, be my guest.
I have a test file for unmasked exceptions, but I don't know how to incorporate it into the phobos tests.
A test for
roundToNearestis missing, because I'm having a hard time thinking of one.