| Issue |
115378
|
| Summary |
[libc] unused function `clear_x87_exceptions`
|
| Labels |
libc
|
| Assignees |
|
| Reporter |
nickdesaulniers
|
While working on the i386 port and debugging an issue with my fenv_t support, I noticed that we're never issuing a `fnclex` instruction.
It looks like 9474ddc3ac8637596f87dd796864353317622672 removed the only call to `clearX87Exceptions`, which was later renamed to `clear_x87_exceptions` in 1c92911e9e1d503c0dfc4367da7f15d0dff50587.
I don't strictly know if `fnclex` is necessary.
Bionic's i386 impl is based on freebsd seems to do so in `fesetexceptflag`, `feholdexcept`, and `feclearexcept` before each `fldenv`.
Bionic's x86_64 impl is based on netbsd and seems to only do so in `feholdexcept`.
musl's i386 and x86_64 impls seems to only do so for `feclearexcept`.
It's not clear to me that it is even necessary? Perhaps the unused function should simply be deleted? Otherwise:
```diff
diff --git a/libc/src/__support/FPUtil/x86_64/FEnvImpl.h b/libc/src/__support/FPUtil/x86_64/FEnvImpl.h
index b77178ea69ea..3f227ef75459 100644
--- a/libc/src/__support/FPUtil/x86_64/FEnvImpl.h
+++ b/libc/src/__support/FPUtil/x86_64/FEnvImpl.h
@@ -122,7 +122,7 @@ LIBC_INLINE uint16_t get_x87_status_word() {
}
LIBC_INLINE void clear_x87_exceptions() {
- __asm__ __volatile__("fnclex" : : :);
+ asm("fnclex");
}
LIBC_INLINE uint32_t get_mxcsr() {
@@ -207,6 +207,7 @@ LIBC_INLINE int clear_except(int excepts) {
internal::get_x87_state_descriptor(state);
state.status_word &=
static_cast<uint16_t>(~internal::get_status_value_for_except(excepts));
+ internal::clear_x87_exceptions();
internal::write_x87_state_descriptor(state);
uint32_t mxcsr = internal::get_mxcsr();
@@ -230,6 +231,7 @@ LIBC_INLINE int set_except(int excepts) {
internal::X87StateDescriptor state;
internal::get_x87_state_descriptor(state);
state.status_word |= status_value;
+ internal::clear_x87_exceptions();
internal::write_x87_state_descriptor(state);
uint32_t mxcsr = internal::get_mxcsr();
```
would do what freebsd does.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
