Fix powerpc-nofpu __fe_enabled_env and __fe_nonieee_env (bug 17261)

  On powerpc, floating-point environment macros are defined as pointers
to constants in the library that contain the bit-patterns of the
desired environment, instead of being magic constants cast to pointer
type.

For soft-float, the bit-patterns used for fenv_t are not laid out the
same as for hard-float.  (e500 has a third layout used; that's not an
ABI issue because these values are only meaningful within a single
process, all of whose glibc libraries must come from the same build of
glibc.)  While the __fe_dfl_env value for soft-float was appropriate
for the soft-float fenv_t representation, the other two constants had
the same bit-patterns as for hard-float.  Those bit patterns had the
effect of having exceptions already raised, causing
math/test-fenv-return to fail; this patch fixes the patterns used.
(__fe_nonieee_env also had exceptions unmasked, though they should be
masked to match hard-float semantics.  Since there is no separate
non-IEEE mode for soft-float, it's most appropriate for
__fe_nonieee_env to be the same as __fe_dfl_env; this patch makes it
an alias.)

Tested for powerpc-nofpu.

2014-08-12  Joseph Myers  <joseph@codesourcery.com>

	[BZ #17261]
	* sysdeps/powerpc/nofpu/fenv_const.c (__fe_enabled_env): Change
	value to 0.
	(__fe_nonieee_env): Define as an alias for __fe_dfl_env.
  

That's ok, thanks. 

Not really related to this patch, I see most of no-fpu code in GLIBC is
focused towards e500.  Do you know if it is 'de facto' no-fpu powerpc ABI
or just a variation?  I'm asking because I am feeling inclined, if e500
is just an possible variation, to try cleanup up nofpu code to put e500
specific code in a e500 folder.


On 12-08-2014 15:07, Joseph S. Myers wrote:
> On powerpc, floating-point environment macros are defined as pointers
> to constants in the library that contain the bit-patterns of the
> desired environment, instead of being magic constants cast to pointer
> type.
>
> For soft-float, the bit-patterns used for fenv_t are not laid out the
> same as for hard-float.  (e500 has a third layout used; that's not an
> ABI issue because these values are only meaningful within a single
> process, all of whose glibc libraries must come from the same build of
> glibc.)  While the __fe_dfl_env value for soft-float was appropriate
> for the soft-float fenv_t representation, the other two constants had
> the same bit-patterns as for hard-float.  Those bit patterns had the
> effect of having exceptions already raised, causing
> math/test-fenv-return to fail; this patch fixes the patterns used.
> (__fe_nonieee_env also had exceptions unmasked, though they should be
> masked to match hard-float semantics.  Since there is no separate
> non-IEEE mode for soft-float, it's most appropriate for
> __fe_nonieee_env to be the same as __fe_dfl_env; this patch makes it
> an alias.)
>
> Tested for powerpc-nofpu.
>
> 2014-08-12  Joseph Myers  <joseph@codesourcery.com>
>
> 	[BZ #17261]
> 	* sysdeps/powerpc/nofpu/fenv_const.c (__fe_enabled_env): Change
> 	value to 0.
> 	(__fe_nonieee_env): Define as an alias for __fe_dfl_env.
>
> diff --git a/sysdeps/powerpc/nofpu/fenv_const.c b/sysdeps/powerpc/nofpu/fenv_const.c
> index 6dc9e6f..39f53dd 100644
> --- a/sysdeps/powerpc/nofpu/fenv_const.c
> +++ b/sysdeps/powerpc/nofpu/fenv_const.c
> @@ -27,8 +27,8 @@ const unsigned long long __fe_dfl_env __attribute__ ((aligned (8))) =
>
>  /* Floating-point environment where none of the exceptions are masked.  */
>  const unsigned long long __fe_enabled_env __attribute__ ((aligned (8))) =
> -0xfff80000000000f8ULL;
> +0x0000000000000000ULL;
>
> -/* Floating-point environment with the NI bit set.  */
> -const unsigned long long __fe_nonieee_env __attribute__ ((aligned (8))) =
> -0xfff8000000000004ULL;
> +/* Floating-point environment with the NI bit set.  No difference for
> +   soft float from the default environment.  */
> +strong_alias (__fe_dfl_env, __fe_nonieee_env)
>
  

On Tue, 12 Aug 2014, Adhemerval Zanella wrote:

> That's ok, thanks. 
> 
> Not really related to this patch, I see most of no-fpu code in GLIBC is
> focused towards e500.  Do you know if it is 'de facto' no-fpu powerpc ABI
> or just a variation?  I'm asking because I am feeling inclined, if e500
> is just an possible variation, to try cleanup up nofpu code to put e500
> specific code in a e500 folder.

e500 uses the same ABI as ordinary nofpu.  The e500 code is all in 
sysdeps/powerpc/powerpc32/e500/nofpu/ (plus one Implies file in 
sysdeps/unix/sysv/linux/powerpc/powerpc32/e500/nofpu/).