Bug#237373: libc6-dev: support for fegetprec / fesetprec to control the dynamic precision modes
On 2004-03-12 20:50:20 +0900, GOTO Masanori wrote:
> Thanks for your detailed explanation, I understand this is about
> manipulating wrapper function of x87 precious control field. The
> similar symbol is already defined in fpu_control.h like _FPU_EXTENDED
> and so, on i386/adm64/m68k/sparc.
/usr/include/fpu_control.h on x86 defines:
/* precision control */
#define _FPU_EXTENDED 0x300 /* libm requires double extended precision. */
#define _FPU_DOUBLE 0x200
#define _FPU_SINGLE 0x0
but these macros are not defined on PPC since it doesn't support
dynamic precision control. So, one should probably have things
like
#ifdef _FPU_EXTENDED
#define FE_LDBLPREC whatever
#endif
> I understand this is sometimes useful when a user want to change the
> precision of FPU. But, the problem is it's extended function, not
> standard. soft-fp in glibc uses EXTENDED, and don't recommend SINGLE.
> I found recent Solaris on x86 only defines it. Is this function
> future-rock?
Well, one never knows. Perhaps this needs discussions with other
C library developers (e.g. from *BSD) to agree on a de facto
standard. But the one from the C99 draft would probably be the
most logical one.
I think that these should be defined only if __USE_GNU is defined
(just like the exp10 function, which is a GNU extension, but may
also be available with other C libraries, e.g. under Solaris).
Also note that if the user changes the rounding precision (with either
these functions or with the existing fpu_control.h macros or another
method), functions from the libm may fail, but anyway this would be a
libm bug (and I'd regard it as a part of bug 153022).
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Reply to: