Port-i386 archive

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

Re: Changing x87 precision to full 63bit as default



  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.

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.  I know we don't usually do this, and reveiw bare
patches (vs what would be posted as a draft commit in git or hg), but
for patches that significantly change behavior it seems like a good
idea.

  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.

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

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?

Attachment: pgpLge33c1IQf.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index