mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: [musl] Excess precision hell
Date: Sun, 9 Feb 2020 12:02:01 -0500	[thread overview]
Message-ID: <20200209170201.GP1663@brightrain.aerifal.cx> (raw)

Recent finds in GCC bug tracker and experimentation with GCC and clang
have me rather concerned about the safety of code built for i386. Some
background references:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

At one point I'd almost thought we should remove -ffloat-store as a
fallback for -fexcess-precision=standard on old GCCs, but it turns out
that's a really bad idea. GCC (perhaps wrongly? this isn't clear from
psABI) assumes that function call results don't have excess precision,
so generating a libc.a/libc.so where they can return excess precision
is dangerous (lies to the optimizer, leading to things like 85957
above). Using -ffloat-store produces results that are numerically
wrong (not to mention slow), but at least consistent and
deterministic.

Unfortunately clang does not support either -ffloat-store or
-fexcess-precision=standard, so **all** versions of musl build for
i386 by clang are seriously broken in this regard. The only way I've
found to make clang drop excess precision is by casting/coercing (by
return statement) down from long double to double or float. (And note
that a simple gratuitous cast up/down doesn't help; there actually
needs to be a floating point operation that's been evaluated in the
higher precision.)

So, our code that's using float_t/double_t internally is presumably
clang-safe, but there's a lot that's not doing that yet -- single
precision hyperbolic functions and special functions, all complex
math, maybe other things too.

We probably should deprecate or disallow building of i386 musl with
clang (unless -march is such that sse2 math is available and can be
used, in which case there's no excess precision and everything is
fine) unless/until everything is converted to use of float_t/double_t,
or conditional on a test for a fix in clang. (For example we could
write a configure test that disallows use of clang if x+y generates
fadd but not fst[p]l in the asm.) Does this sound reasonable?

One thing I just found, but I don't know if it's reliable: it seems
clang's -O0 gives the equivalent of -ffloat-store. So perhaps we could
just force -O0 (just for src/math and src/complex?) if clang is
detected as having this bug.

Rich

                 reply	other threads:[~2020-02-09 17:02 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200209170201.GP1663@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).