Differences between glibc and kernel soft-fp

["Joseph S. Myers" <joseph at codesourcery dot com>]

I've examined the differences between the Linux kernel version of
soft-fp (include/math-emu) and glibc's code (as of 2.3.5, a reasonable
approximation to the version used by the kernel - though 2.3.5
evidently has some changes not in the kernel, if I try to find an
older common ancestor it looks like lots of the changes up to around
2.3.5 went in both places).  Various changes have also gone into
glibc, or had equivalent changes go in so they should not be needed if
the kernel updates to the current glibc version.  The following other
changes in the kernel remain (the changes to the glibc code that are
not in the kernel are much more substantial).  What do people think of
adding equivalent features to the glibc version so that it would be
usable by the kernel?  If I were to do so, is anyone interested in
volunteering to update the kernel (including converting all the users
of the code in the kernel for the changed interfaces regarding macros
now using raw or semi-raw values)?

In the git era (including one change that may not be needed, but seems
worthy of comment):

* 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.

* commit 48d6c64311ddb6417b901639530ccbc47bdc7635, "math-emu: Add
  support for reporting exact invalid exception" (and followup typo
  fix 60b8267338aafde5315fc65ff385f3d4d75eccfe).  Distinguishes
  exceptions for sNaN inputs, inf - inf, inf / inf, 0 / 0, inf * 0,
  for powerpc emulation; should be doable in a way that does not
  change the code generated if the new variants aren't defined.

(As previously discussed, commit
f8324e20f8289dffc646d64366332e05eaacab25 addressed an issue fixed by
my 2005-6 changes.  commit 930cc144a043ff95e56b6888fa51c618b33f89e7
addressed an issue that should be fixed by my patch
<https://sourceware.org/ml/libc-alpha/2013-10/msg00338.html>.)

That takes us back to Linux 2.6.12.  Older potentially relevant
changes in the kernel (which I haven't tried to trace to where they
were originally added) are:

* Addition of FP_TO_INT_ROUND macros (converting from floating point
  to integer according to the current rounding direction).

* rsigned == 2 in FP_TO_INT (and FP_TO_INT_ROUND) macros, a case where
  out-of-range values get the integer result reduced modulo an
  appropriate power of 2 rather than saturated; it's far from apparent
  to me that the code ensures all shifts are valid, but I haven't
  checked in detail.  (Used only by alpha.)

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

* Support for FP_DENORM_ZERO, flushing subnormals to zero on input.

* 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.

In summary:

(a) Does FP_TO_INT_ROUND seem appropriate even if not used in glibc?
(It could actually be used in glibc as a basis for implementing lrint
/ llrint more efficiently on systems using software floating point.)

(b) Does rsigned == 2 seem appropriate even if not used in glibc?

(c) Does support for the more precise "invalid" exceptions seem
appropriate even if not used in glibc?

(d) Does FP_DENORM_ZERO seem appropriate even if not used in glibc?

(e) Is anyone interested in getting the kernel using the current
version of soft-fp, if those four features are added to it?

-- 
Joseph S. Myers
joseph@codesourcery.com