Date: Sun, 23 Feb 2020 19:14:08 +0300 (MSK) From: Alexander Monakov <amonakov@...ras.ru> To: musl@...ts.openwall.com Subject: Re: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.