From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 1ed2600f for ; Sun, 9 Feb 2020 17:02:18 +0000 (UTC) Received: (qmail 17509 invoked by uid 550); 9 Feb 2020 17:02:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 17475 invoked from network); 9 Feb 2020 17:02:14 -0000 Date: Sun, 9 Feb 2020 12:02:01 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200209170201.GP1663@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: [musl] Excess precision hell 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