From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-hacker-return-9218-listarch-libc-hacker=sources.redhat.com@sourceware.org>
Received: (qmail 1638 invoked by alias); 14 Apr 2007 17:32:19 -0000
Received: (qmail 1622 invoked by uid 22791); 14 Apr 2007 17:32:19 -0000
X-Spam-Check-By: sourceware.org
Received: from sunsite.ms.mff.cuni.cz (HELO sunsite.mff.cuni.cz) (195.113.15.26)
    by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 14 Apr 2007 18:32:17 +0100
Received: from sunsite.mff.cuni.cz (localhost.localdomain [127.0.0.1])
	by sunsite.mff.cuni.cz (8.13.8/8.13.8) with ESMTP id l3EHce94019043;
	Sat, 14 Apr 2007 19:38:40 +0200
Received: (from jakub@localhost)
	by sunsite.mff.cuni.cz (8.13.8/8.13.8/Submit) id l3EHcdka019042;
	Sat, 14 Apr 2007 19:38:39 +0200
Date: Sat, 14 Apr 2007 17:32:00 -0000
From: Jakub Jelinek <jakub@redhat.com>
To: Steven Munroe <munroesj@us.ibm.com>
Cc: Glibc hackers <libc-hacker@sources.redhat.com>,
        Ulrich Drepper <drepper@redhat.com>,
        Peter Eberlein <eberlein@us.ibm.com>
Subject: Re: [PATCH] PPC fenv fixes. 3rd update
Message-ID: <20070414173839.GL1826@sunsite.mff.cuni.cz>
Reply-To: Jakub Jelinek <jakub@redhat.com>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <46157538.5050407@us.ibm.com>
User-Agent: Mutt/1.4.2.2i
Mailing-List: contact libc-hacker-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-hacker.sourceware.org>
List-Subscribe: <mailto:libc-hacker-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-hacker/>
List-Post: <mailto:libc-hacker@sourceware.org>
List-Help: <mailto:libc-hacker-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-hacker-owner@sourceware.org
X-SW-Source: 2007-04/txt/msg00007.txt.bz2

On Thu, Apr 05, 2007 at 05:16:24PM -0500, Steven Munroe wrote:
> > You should be using magic numbers, like in the i386 port.
> >
> >   
> Upated the patch to define FE_NOMASK_ENV as FE_ENABLED_ENV and
> FE_MASK_ENV as FE_DFL_ENV. On PPC we can't use magic numbers because
> fesetenv takes (fenc_t *envp).

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.

> +  GLIBC_2.4 {
> +    # symbols used in macros from sysdeps/powerpc/bits/fenv.h
> +    __fe_mask_env;
> +  }

Current glibc development uses GLIBC_2.6.  But I don't think you
want to export this at all.

> +  /* If the old env has no eabled exceptions and the new env has any enabled
> +     exceptions, then unmask SIGFPE in the MSR FE0/FE1 bits.  This will put
> +     the hardware into "precise mode" and may cause the FPU to run slower on
> +     some hardware.  */
> +  if ((old.l[1] & 0x000000F8) == 0 && (new.l[1] & 0x000000F8) != 0)
> +    __fe_nomask_env;

I thought __fe_nomask_env is a function, so __fe_nomask_env just evaluates
to the address of that function and is being thrown away immediately, i.e.
a nop.

> +  /* If the old env had any eabled exceptions and the new env has no enabled
> +     exceptions, then mask SIGFPE in the MSR FE0/FE1 bits.  This may allow the
> +     FPU to run faster because it always takes the default action and can not 
> +     generate SIGFPE. */
> +  if ((old.l[1] & 0x000000F8) != 0 && (new.l[1] & 0x000000F8) == 0)
> +    __fe_mask_env;

Here too and in several other places as well.

	Jakub