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:
pgpK61T5SXRIq.pgp
Description: PGP signature