From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4240 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: math_errhandling definition Date: Mon, 18 Nov 2013 14:59:31 -0500 Message-ID: <20131118195931.GK24286@brightrain.aerifal.cx> References: <20131117215454.GA9505@duality.lan> <20131117231325.GZ1685@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1384804783 25673 80.91.229.3 (18 Nov 2013 19:59:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Nov 2013 19:59:43 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4244-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 18 20:59:49 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ViUz4-0006vd-3K for gllmg-musl@plane.gmane.org; Mon, 18 Nov 2013 20:59:46 +0100 Original-Received: (qmail 11746 invoked by uid 550); 18 Nov 2013 19:59:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11735 invoked from network); 18 Nov 2013 19:59:44 -0000 Content-Disposition: inline In-Reply-To: <20131117231325.GZ1685@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4240 Archived-At: On Mon, Nov 18, 2013 at 12:13:25AM +0100, Szabolcs Nagy wrote: > * Bobby Bingham [2013-11-17 15:54:54 -0600]: > > I think the definition of math_errhandling is wrong on a couple > > architectures. C99 (7.12) says: > > > > If the expression math_errhandling & MATH_ERREXCEPT can be nonzero, > > the implementation shall define the macros FE_DIVBYZERO, FE_INVALID, > > and FE_OVERFLOW in . > > > > math.h always defines math_errhandling as 2 (MATH_ERREXCEPT), but > > whether those FE_* macros are defined or not is architecture-dependent. > > In particular, ARM only defines them if __ARM_PCS_VFP is defined, and > > microblaze does not define them. > > > > It looks like if the architecture doesn't support floating point > > exceptions, math_errhandling must be MATH_ERRNO. This in turn requires > > that the various math functions set errno appropriately, which it > > doesn't look like musl's do. > > yes, but.. > > musl aims to support annex f > > annex f requires math_errhandling & MATH_ERREXCEPT to be true > ie math errors are reported as floating-point exceptions > according to ieee 754 semantics > > annex f also requires all five ieee status flags to be defined > FE_OVERFLOW, FE_UNDERFLOW, FE_DIVBYZERO, FE_INVALID, FE_INEXACT > > (c99 requires that unsupported flags are not defined and has > weaker requirements without annex f as you quoted) > > unfortunately c99 made it (nearly) impossible to implement > floating-point with ieee exception semantics in software and > indeed gcc does not provide exceptions for fpu-less archs > (unless the underlying arch has hw registers for it) > > this is fixed in c11 which changed signal handler semantics wrt > the floating-point environment and introduced thread storage > duration (however libgcc does not implement fp status flags with > thread storage duration just yet) > > musl can only support annex f if the underlying hardware > (or on fpu-less archs the compiler or kernel fp emulation) > support ieee754 > > in short this should be reported against libgcc > > in theory we could support MATH_ERRNO on such platforms, but > it would be a significant effort and still would not give useful > fp semantics other than slightly stricter c99 conformance Yes, nsz summed this up very nicely. Bobby, is there a practical issue you're hitting with the lack of math_errhandling on these archs, or are you just concerned with conformance from a theoretical standpoint? I ask mainly because this will help us consider how to deal with the issue in the future and what to prioritize. My general feeling right now is that ARM users should prefer the "armhf" ABI whenever possible, and that using microblaze for floating point computation is just a bad idea to begin with. But we'll have to consider other archs as they are added (if others lack fp exceptions ABIs) and whether proper soft-float with exceptions is on the way... Rich