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 c12fdfe1 for ; Sun, 23 Feb 2020 00:19:56 +0000 (UTC) Received: (qmail 32137 invoked by uid 550); 23 Feb 2020 00:19:55 -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 32118 invoked from network); 23 Feb 2020 00:19:54 -0000 Date: Sat, 22 Feb 2020 19:19:42 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200223001942.GM1663@brightrain.aerifal.cx> References: <20200114185058.GV23985@port70.net> <20200114185835.GG30412@brightrain.aerifal.cx> <20200206145156.GF1663@brightrain.aerifal.cx> <20200222195925.GK1663@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Q: dealing with missing removal of excess precision On Sat, Feb 22, 2020 at 11:21:58PM +0300, Alexander Monakov wrote: > On Sat, 22 Feb 2020, Rich Felker wrote: > > > Can you comment on these bugs? Now that the 1.2.0 release is out I'd > > like to follow up with reviewing/merging these. > > Sure, but before I do that I'd like to understand better how the review > process is going to work. > > In particular, wouldn't it make more sense to wait until after you make > your round of reviews, so that your examination is not biased by what > I reveal? 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. Rich