From owner-freebsd-arm@FreeBSD.ORG Tue Jan 17 20:15:10 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8966106564A for ; Tue, 17 Jan 2012 20:15:09 +0000 (UTC) (envelope-from das@freebsd.org) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id A35828FC13 for ; Tue, 17 Jan 2012 20:15:09 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q0HKF7PC056320; Tue, 17 Jan 2012 15:15:07 -0500 (EST) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q0HKF7Vx056319; Tue, 17 Jan 2012 15:15:07 -0500 (EST) (envelope-from das@freebsd.org) Date: Tue, 17 Jan 2012 15:15:07 -0500 From: David Schultz To: Ian Lepore Message-ID: <20120117201506.GA56160@zim.MIT.EDU> References: <20120114081214.GA14925@zim.MIT.EDU> <1326563626.1678.34.camel@revolution.hippie.lan> <20120114182933.GA17739@zim.MIT.EDU> <1326568038.1678.43.camel@revolution.hippie.lan> <20120114211039.GA18310@zim.MIT.EDU> <1326591214.1678.85.camel@revolution.hippie.lan> <20120116022647.GA36657@zim.MIT.EDU> <1326730552.1669.29.camel@revolution.hippie.lan> <20120116195113.GA87187@zim.MIT.EDU> <1326827437.1669.148.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1326827437.1669.148.camel@revolution.hippie.lan> Cc: freebsd-arm Subject: Re: fenv.h fixes for softfloat X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 20:15:10 -0000 On Tue, Jan 17, 2012, Ian Lepore wrote: > To get that output, I had to change __softfloat_float_exception_flags to > be declared as volatile in all 3 places it's mentioned (two extern decls > and the definition). I tried just casting to volatile in > fetestexception() and that alone wasn't enough to printf everything > correctly. [...] > You can see the insanity there that drove me to try using volatile: > rint() says it has raised INEXACT just before returning, but printing > the flags immediately upon return from rint() showed 0. But, note that > the flag variable was correct because the final feupdateenv() raised it > again, so the second feholdenv() must have seen it set, right? > > But if you can't print the right values along the way, then the compiler > is somehow feeling free to re-order the code in such a way that the > printfs don't show the right values. If it could do that in such a way > as to mess up the printfs, could it do so in a way that had more serious > side effects? You've hit on an old problem that affects more than just arm. Unfortunately, gcc assumes that floating-point arithmetic has no side effects, and consequently, at higher optimization levels, it often reorders computations incorrectly. C99 specifies an FENV_ACCESS pragma intended to enable or disable such optimizations, but only commercial compilers implement it. You can often force gcc to do the right thing with -frounding-math or lower optimization levels. If declaring the flags variable volatile is enough to get things working, more or less, then perhaps we ought to do that until we have a real 21st-century compiler. Even with the FENV_ACCESS issues fixed, there's another problem. The routines that emulate fp-to-integer conversions (__fixdfdi et al.) are traditionally in the compiler runtime library (libgcc), not libc. If your program links against the symbol from libgcc, that implementation has no way of signaling exceptions, since the rest of the softfloat stuff is in libc. FreeBSD and Linux have most of the symbols in libc as well (for reasons that are mysterious to me), so if you get the libc version, then it might work. See also: http://gcc.gnu.org/wiki/Software_floating_point I can fix some inadequacies in the emulation in FreeBSD's libc, but if programs are getting linked properly, that won't have any effect. I wouldn't worry too much about the exceptions for now, in any case. Programs that actually check them are pretty rare, although that's partly due to the lack of compiler support. If libm functions are producing the right answers, more or less, then things are working well enough for most purposes.