From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32263 invoked by alias); 30 Apr 2007 21:45:25 -0000 Received: (qmail 32247 invoked by uid 22791); 30 Apr 2007 21:45:24 -0000 X-Spam-Check-By: sourceware.org Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Apr 2007 22:45:20 +0100 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.11.20060308/8.13.8) with ESMTP id l3ULg5ka003722 for ; Mon, 30 Apr 2007 17:42:05 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3ULjAp2192048 for ; Mon, 30 Apr 2007 15:45:10 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3ULjAKl031191 for ; Mon, 30 Apr 2007 15:45:10 -0600 Received: from [9.10.86.122] (spokane1.rchland.ibm.com [9.10.86.122]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3ULj9pc031165; Mon, 30 Apr 2007 15:45:09 -0600 Message-ID: <46366787.2070202@us.ibm.com> Date: Mon, 30 Apr 2007 21:45:00 -0000 From: Steven Munroe User-Agent: Mozilla/5.0 (X11; U; Linux ppc64; en-US; rv:1.8.0.9) Gecko/20060906 SUSE/1.8_seamonkey_1.0.7-1.1 SeaMonkey/1.0.7 MIME-Version: 1.0 To: Jakub Jelinek , Glibc hackers , Richard Henderson CC: Ulrich Drepper , Peter Eberlein Subject: Re: [PATCH] PPC fenv fixes. 3rd update References: <20070322145345.GZ1826@sunsite.mff.cuni.cz> <4602FCE5.7060203@us.ibm.com> <460941B8.2050501@us.ibm.com> <20070327160708.GA355@devserv.devel.redhat.com> <46096124.6050504@us.ibm.com> <460A8D78.6060303@us.ibm.com> <20070405022655.GA29766@twiddle.net> <46157538.5050407@us.ibm.com> <20070414173839.GL1826@sunsite.mff.cuni.cz> <20070417000725.GA29690@twiddle.net> <20070417002157.GI355@devserv.devel.redhat.com> In-Reply-To: <20070417002157.GI355@devserv.devel.redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact libc-hacker-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sourceware.org X-SW-Source: 2007-04/txt/msg00014.txt.bz2 Jakub Jelinek wrote: > On Mon, Apr 16, 2007 at 05:07:25PM -0700, Richard Henderson wrote: > >> On Sat, Apr 14, 2007 at 07:38:39PM +0200, Jakub Jelinek wrote: >> >>> Hm, why can't you use the magic numbers? fesetenv takes (fenv_t *envp) >>> on all arches, yet all but ppc manage to handle magic numbers. >>> >> Assuming a userland has all bits available for user mapping, >> there may be no easy space to reserve. In which case I'd export >> some dummy variables from libc, and compare vs their addresses. >> > > Even then, as fenv_t is 64-bit on ppc (double), values > (const fenv_t *)-7 through (const fenv_t *)-1 can be safely used > as magic numbers - a valid fenv_t object can't cross the end of > the address space. > > Sorry for the delayed responce, I was on vacation. Actually the problem is the FPSCR is floating point register and can only be transfer to/from a FPR. That is why fenv_t is defined as double *. Also with Power6 the FPSCR contains DFP rounding bits in the high 32-bits of the double. So passing a magic number that is not a double or a pointer to double would require an extra GPR store just to reload it as an FPR for transfer to the FPSCR. This would only complicate things. Also FE_ENABLED_ENV and FE_DFL_ENV are #defines to the addresses of existing static doubles which already contain the appropriate magic numbers. So why shouldn't I use them?