Re: Changing x87 precision to full 63bit as default

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Thu, Nov 07, 2013 at 07:52:43AM -0500, Greg Troxel wrote:
> 
>   as discussed a while ago, I would like to change the initial x87
>   configuration to the system default, aka long double precision.
>   This makes it possible to get working long double. A review of the libm
>   assembler routines will follow to make sure they do correct rounding.
> 
> Does this change affect just i386, or also amd64?  If I follow
> correctly, it will change the behavior of programs on amd64 that use x87
> instructions rather than SSE, but that's an odd case, and therefore the
> behavior of almost all actual programs on amd64 will not change.
> Further, the floating point results on i386 will, post-patch, match the
> results on amd64.  Explaining the above (correclty, which I may not have
> done) belongs in the commit message.

Normal float and double operation on AMD64 are using SSE2, so they would
not be affected.

> I think you should post the draft commit message (in addition to just
> the diffs), and have it explain why the new behavior conforms to
> relevant standards, with sufficient detail that it's understandable to
> most developers.

The standards have always allowed excessive precision. There are ways to
force rounding (volatile being one of them), but explaining all this is
outside the scope of a commit message.

>   The patch checks the version of the main binary, so that old binaries
>   will keep working. libm will update the global fenv.h environment to
>   match whatever the kernel is using. The mixing should be harmless as
>   long as only double routines are used, new long double routines will
>   naturally not give the full precision for old binaries.
> 
> This also needs more explanation.  You say "keep working", but it's not
> immediately clear exactly what that means.  Is that about the precision
> being defined in a .h file rather than being obtained dynamically, and
> wanting to honor that compiled-in precision for binaries that were built
> against the older .h file?  Presumably the vast majority of programs
> that don't look at the fenv.h variables will behave (slightly)
> differently when newly compiled, but because they didn't check, they
> have no right to expect any particular precision.  This aspect also
> should be explained more clearly in the comments.

Old binaries will get the same FPU environment as before. If they are
using either fenv.h, volatile or FLT_EVAL_METHOD, they will adjust correctly
on recompile.

> The patch does not change documentation, but it changes longstanding
> behavior and the backwards compat beahvior is (while reasonable)
> non-obvious.  So it seems this belongs in some manpage, presumably
> fenv(3).

We haven't documented it at all, AFAIK. fenv(3) doesn't make sense as
this is a highly MD implementation detail.

> Have you run paranoia (with no math options in CFLAGS) with the patch?
> Is it happy with everything?  If not, can you explain what it objects
> to, and why it is wrong?

I haven't and I don't plan to.

Joerg