From owner-freebsd-arm@FreeBSD.ORG Fri Jan 20 17:55:39 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 0859D1065670 for ; Fri, 20 Jan 2012 17:55:39 +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 A0E3F8FC1C for ; Fri, 20 Jan 2012 17:55:38 +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 q0KHtZ91039692; Fri, 20 Jan 2012 12:55:35 -0500 (EST) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q0KHtZw0039691; Fri, 20 Jan 2012 12:55:35 -0500 (EST) (envelope-from das@freebsd.org) Date: Fri, 20 Jan 2012 12:55:35 -0500 From: David Schultz To: Ian Lepore Message-ID: <20120120175535.GA39600@zim.MIT.EDU> References: <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> <20120117201506.GA56160@zim.MIT.EDU> <1327071938.13801.9.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1327071938.13801.9.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: Fri, 20 Jan 2012 17:55:39 -0000 On Fri, Jan 20, 2012, Ian Lepore wrote: > On Tue, 2012-01-17 at 15:15 -0500, David Schultz wrote: > > 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. > > I've been pondering this for a couple days, and I think it's probably a > good idea. The problem seems to be that the compiler and optimizer are > unaware of the fact that the fenv stuff can change across certain > operations, and 'volatile' tells the compiler exactly "this value can > change in ways you are unaware of." I can't think of any downside other > than trying to figure out/remember 5 years from now why the variable is > volatile, and that can be fixed with a little comment nearby. To address another issue, I tweaked the implementation in r23036 so that none of the fenv routines are inlined anymore. This should achieve the same result as declaring the variables volatile. The compiler may still assume that it can reorder the floating-point computations around the function calls, however. That's partly what FENV_ACCESS is intended to address. By the way, I checked in a new test in tools/regression/usr.bin/cc, which covers some of the more rudimentary things about the compiler and FP emulation than the libm tests do. It might provide some insight into what needs to be fixed for the libm tests to pass, although I think I know what the answer is, and it's not clear that it's worth the trouble of fixing. > Oh, another thing I've been meaning to mention... Doesn't the mips > platform also use software floating point? If so, then I think > libc/mips/gen/flt_rounds.c needs to be modified to look more like the > one I did for arm, with separate software and hardware implementations. Yes, probably. I haven't looked at it much for lack of time, and because of the difficulties of doing development for platforms I don't have. The MIPS code appears to have been copied from the ARM code verbatim in most cases, so I'm fairly confident that it's all wrong.