Joerg Sonnenberger <joerg%britannica.bec.de@localhost> writes: > one major difference between the existing softfloat support in libc and > compiler-rt's softfloat implementation is the (non)support for > rounding modes. libc supports some global variables for that, which is > of limited usefulness in a multi-threaded world. Making them fully > thread-local on the other hand is quite expensive. A discussion with the > responsible developer of the compiler-rt code and some LLVM folks > resulting in the suggestion of providing an alternative set of entry > points, where the float environment is an explicit argument, if this > feature is really desirable. Long story short, does anyone use > non-default rounding modes on platforms with softfloat? I certainly don't, but pkgsrc/benchmarks/paranoia seems to check things like this, and it seems a regression to have that do worse. I am not sure I understand your global vs thread-local concern - the real issue is lexical source-code scope rather than dynamic thread context. I would expect that non-default rounding is most used in FORTRAN code that doesn't tend to end up in the same binary as other floating point code. I would lean towards having a single static value. That's what fpsetmode(3) and fenv.h seem to expect, and not supporting that usage seems nonconformant: http://pubs.opengroup.org/onlinepubs/000095399/basedefs/fenv.h.html http://pubs.opengroup.org/onlinepubs/000095399/functions/fegetround.html
Attachment:
pgpTTcoTB3flE.pgp
Description: PGP signature