| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
linux, gcc, etc. all use "sh" as the name for the superh arch. there
was already some inconsistency internally in musl: the dynamic linker
was searching for "ld-musl-sh.path" as its path file despite its own
name being "ld-musl-superh.so.1". there was some sentiment in both
directions as to how to resolve the inconsistency, but overall "sh"
was favored.
|
| |
|
|
|
|
| |
the build system has no automatic way to know this code applies to
both big (default) and little endian variants, so explicit .sub files
are needed.
|
| |
|
|
|
|
|
|
|
| |
Userspace emulated floating-point (gcc -msoft-float) is not compatible
with the default mips abi (assumes an FPU or in kernel emulation of it).
Soft vs hard float abi should not be mixed, __mips_soft_float is checked
in musl's configure script and there is no runtime check. The -sf subarch
does not save/restore floating-point registers in setjmp/longjmp and only
provides dummy fenv implementation.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
the default fenv was not set up properly, in particular the
tag word that indicates the contents of the x87 registers was
set to 0 (used) instead of 0xffff (empty)
this could cause random crashes after setting the default fenv
because it corrupted the fpu stack and then any float computation
gives NaN result breaking the program logic (usually after a
float to integer conversion).
|
| |
|
|
|
|
| |
i386 fenv code checks __hwcap for sse support, but in fesetround the sse
code was unconditionally jumped over after the test so the sse rounding
mode was never set.
|
| |
|
|
|
| |
there is no non-dot version of the andis instruction, but there's no
harm in updating the flags anyway, so just use the dot version.
|
| |
|
|
|
|
|
|
|
|
|
| |
fesetround.c is a wrapper to do the arch independent argument
check (on archs where rounding mode is not stored in 2 bits
__fesetround still has to check its arguments)
on powerpc fe*except functions do not accept the extra invalid
flags of its fpscr register
the useless FENV_ACCESS pragma was removed from feupdateenv
|
| |
|
|
|
|
|
| |
the x87 exception summary (ES) and stack fault (SF) flags may be
spuriously cleared by feclearexcept using the fnclex instruction,
but these flags are not observable through libc hence maintaining
their state is not critical.
|
| |
|
|
|
|
|
| |
the sse and x87 rounding modes should be always the same,
the visible exception flags are the bitwise or of the two
fenv states (so it's enough to query the rounding mode or
raise exceptions on one fenv)
|
| | |
|
| |
|
|
|
| |
patch by nsz. I've tested it on an armhf machine and it seems to be
working correctly.
|
| |
|
|
| |
based on code sent to the mailing list by nsz, with minor changes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
untested; may need followup-fixes.
|
| |
|
|
|
| |
if all exception flags will be cleared, we can avoid the expensive
store/reload of the environment and just use the fnclex instruction.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that the new fesetround has slightly different semantics:
Storing the floating-point environment with fnstenv makes the
next fldenv (or fldcw) "non-signaling", so unmasked and pending
exceptions does not invoke the exception handler.
(These are rare since exceptions are handled immediately and by
default all exceptions are masked anyway. But if one manually
unmasks an exception in the control word then either sets the
corresponding exception flag in the status word or the execution
of an exception raising floating-point operation gets interrupted
then it may happen).
So the old implementation did not trap in some rare cases
where the new implementation traps.
However POSIX does not specify anything like the x87 exception
handling traps and the fnstenv/fldenv pair is significantly slower
than the fnstcw/fldcw pair (new code is about 5x faster here and
it's dominated by the function call overhead).
|
| | |
|
| | |
|
| | |
|
|
|
at present the i386 code does not support sse floating point, which is
not part of the standard i386 abi. while it may be desirable to
support it later, doing so will reduce performance and require some
tricks to probe if sse support is present.
this first commit is i386-only, but it should be trivial to port the
asm to x86_64.
|
