lib/48384: some libm sources are incompatible with struct ieee_ext on some archs

[martin%NetBSD.org@localhost]

>Number:         48384
>Category:       lib
>Synopsis:       some libm sources are incompatible with struct ieee_ext on 
>some archs
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 17 14:55:00 +0000 2013
>Originator:     Martin Husemann
>Release:        NetBSD 6.99.27
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD thirdstage.duskware.de 6.99.27 NetBSD 6.99.27 (MODULAR) #62: Fri 
Nov 15 12:44:00 CET 2013 
martin%thirdstage.duskware.de@localhost:/usr/src/sys/arch/sparc64/compile/MODULAR
 sparc64
Architecture: sparc64
Machine: sparc64
>Description:

As witnessed by recent (new) test failures of fmodl() on sparc64, some code
in libm does not deal properly with the ieee_ext structure definition used
on ports where long double is 128bit. 

A quick glance shows the following files: 

e_fmodl.c s_ceill.c s_floorl.c s_fmaxl.c s_fminl.c s_frexpl.c
s_nextafterl.c s_nexttoward.c s_nexttowardf.c s_rintl.c s_truncl.c

assume mantissa is represented as ext_frach and ext_fracl, where on at least
hppa, mips64 and sparc64 we have additionally ext_frachm and ext_fraclm.

One option for fixing may be: change the struct ieee_ext definitions, making
ext_frach based on uint64_t (merging frachm into it) and joining fraclm and
fracl into a single uint64_t ext_fracl. No idea what fallout that would
cause.

The other option, of course, is making the libm code aware of the midle 
mantissa parts, #ifdef EXT_FRACLMBITS, but that might get messy.

>How-To-Repeat:
code inspection

>Fix:
n/a