This is the mail archive of the libc-hacker@sourceware.org mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |