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 7a6ed501 for ; Sun, 19 Jan 2020 10:42:23 +0000 (UTC) Received: (qmail 15561 invoked by uid 550); 19 Jan 2020 10:42: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 15524 invoked from network); 19 Jan 2020 10:42:19 -0000 Date: Sun, 19 Jan 2020 11:42:07 +0100 From: Szabolcs Nagy To: musl@lists.openwall.com Message-ID: <20200119104207.GI23985@port70.net> Mail-Followup-To: musl@lists.openwall.com References: <20200116161427.GO30412@brightrain.aerifal.cx> <20200116193343.GP30412@brightrain.aerifal.cx> <20200117145350.GR30412@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [musl] Considering x86-64 fenv.s to C * Damian McGuckin [2020-01-19 20:07:56 +1100]: > On Fri, 17 Jan 2020, Rich Felker wrote: > > > > x86_64 > > > > > > * In assembler > > > > > > * Why does 'feclearexcept' disrespect the flags by clearing ALL x86 bits? > > > > As you said above, updating x87 status register is expensive because > > the only way to write it is to read-modify-write the whole fenv. But > > since we know on x86_64 we have sse registers, we can just move all > > the flags to the sse register, then use fnclex to clear the x87 one > > inexpensively, and the effective set of raised flags remains the same. > > I am worried about the lack of consistency. > > What if something that is only using (say) 80-bit floating arithmetic comes > back looking for a raised exception in the x87 status register & > MUSL has moved effectively moved it to the mxcsr. only musl internally has to be cosistent, which it is. if anything else looks at fpu status it must look at both x87 and sse status otherwise it will be wrong no matter what musl does (fp operations are outside the control of musl and whoever else tries to look at fpu status) but i think if something looks at fpu status behind the libc it's already wrong: libc can implement fe* however it wants to as long as the behavior follows the language semantics, so internal hw registers are meaningless as soon as a libc call is made. iirc gcc can emit software float code on x86 that uses the x87 status register to record the soft float fenv status, so those bits can change even if there was no hard float instruction, i.e. the flags make sense on the c language level but not on the hw level, if you mix those two levels you are in trouble.