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

[Steven Munroe <munroesj@us.ibm.com>]

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?