Re: [PATCH] PPC fenv fixes. 3rd update

[Jakub Jelinek <jakub@redhat.com>]

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