glibc soft-fp ready for kernel use

[Joseph Myers <joseph at codesourcery dot com>]

Updating the comparison of glibc and Linux kernel soft-fp versions from 
<https://sourceware.org/ml/libc-alpha/2013-10/msg00345.html>, I think the 
glibc code is now ready to replace the kernel version if anyone is 
interested in making the relevant kernel changes (which would be fairly 
substantial, given all the interface changes in soft-fp in the past ten 
years or so, especially the conversion of various macros to use raw or 
semi-raw values for speed).

Specifically, all the substantive features listed there from the kernel 
version are now implemented in the glibc version, and the identified bug 
fixes have equivalent fixes in the glibc version.  The following are not 
in the glibc version (the first two I start from an expectation that they 
aren't needed any more, the last two I think it would be fine for the 
glibc and kernel versions to remain different in those areas only):

* commit 40d3057ac036f2501c1930728a6179be4fca577b, "math-emu: Fix
  compiler warnings".  Actually, I suspect those warnings indicate a
  bug in a macro other than the one changed, or in how kernel code is
  using macros, so my default presumption is that this patch is not
  appropriate and not needed with current soft-fp.

* Initializations in _FP_FRAC_DECL_* and _FP_DECL - as above, I think
  these are inappropriate and could be covering up other bugs.

* Multiple-include guards on individual headers (added in the kernel,
  or, in the case of soft-fp.h, the specific guard macros changed).  I
  think the op-*.h headers included by soft-fp.h should probably be
  like bits/*.h in giving an error if not included from soft-fp.h, but
  headers such as single.h might reasonably have such guards added,
  even if the style in glibc would be different from in the kernel.

* Changes to paths by which headers include each other (maybe
  appropriate conditionals on __KERNEL__ can be used to allow a single
  version to be shared).  If the only differences between the glibc
  and kernel versions can be these last two items, that would be good
  even if we can't completely unify the versions.

-- 
Joseph S. Myers
joseph@codesourcery.com