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 02cabef0 for ; Sun, 23 Feb 2020 16:14:22 +0000 (UTC) Received: (qmail 30659 invoked by uid 550); 23 Feb 2020 16:14:20 -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 30638 invoked from network); 23 Feb 2020 16:14:20 -0000 Date: Sun, 23 Feb 2020 19:14:08 +0300 (MSK) From: Alexander Monakov To: musl@lists.openwall.com In-Reply-To: <20200223001942.GM1663@brightrain.aerifal.cx> Message-ID: References: <20200114185058.GV23985@port70.net> <20200114185835.GG30412@brightrain.aerifal.cx> <20200206145156.GF1663@brightrain.aerifal.cx> <20200222195925.GK1663@brightrain.aerifal.cx> <20200223001942.GM1663@brightrain.aerifal.cx> User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: Re: [musl] Q: dealing with missing removal of excess precision On Sat, 22 Feb 2020, Rich Felker wrote: > I'm not well acquainted with SSE, and only so-so with x87, so pretty > much I'm reading them for higher-level issues with tooling > compatibility (like the concerns I already raised and looked up and > seem to have resolved about x87 constraints and non-GCC compilers) and > logic, then planning to apply and test them. I think being aware of > non-obvious mistake modes that have already been found would be a lot > more useful than staring at things, especially if the bugs you've > found are in subtleties of the insn behavior or constraint behavior. Okay, thanks. I found two issues: 1. i386 lrint* functions mistakenly used fistpll instead of fistpl (I posted the fix for x32 asm after noticing my own mistake). 2. Some functions bind a 32-bit lvalue as output for fnstsw %ax, which as the operand says writes only 16 bits. They should be changed to either use a 16-bit lvalue, or a zero-initialized 32-bit lvalue with "+a" constraint. Plus, not bugs, but still worth mentioning: 3. The new remquol in C could alternatively be implemented by using fxam to extract sign bits instead of loading them from stack slots. The current approach makes sense given the ABI, but an implementation aiming for better code after inlining could choose to use fxam instead of forcing a spill. 4. I did not manage to find a copy of Figueroa's "When is double rounding innocuous", but I could cite e.g. "Innocuous Double Rounding of Basic Arithmetic Operations" by Pierre Roux instead (in i386/sqrtf.c). If you like you can fetch a Git tree with my patches from https://git.sr.ht/~amonakov/musl (issue 1 is already corrected in that repo) Thanks. Alexander