[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

#define FE_LDBLPREC whatever

> 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: