This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PowerPC: Extend fpu fenv operations to operate on 64-bit FPSCR

On Mon, 2007-10-29 at 18:16 -0700, Ulrich Drepper wrote:
> Hash: SHA1
> With this patch I get additional errors.  E.g.:
> $ cat math/test-fpucw.out
> control word is 0xfff8000000000003 but should be 0x0000000000000003.
> - --
> â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
> Version: GnuPG v1.4.7 (GNU/Linux)
> iD8DBQFHJoXd2ijCOnn/RHQRAjTbAJ9gU0OfiRA2aO0siMVqhzh59DPykgCgpHHb
> C3Wjk/RylxyOmq99A2MtfSo=
> =Gxyl

Hi Ulrich,

This error is due to an overly simplistic test-case expectation on my
part but the underlying new FPSCR code is still sound.  I found the same
issue in my new test-powerpc-fenv testcase.

On the pre-POWER6 series of hardware (POWER5, et al) the high order word
of the FPSCR 0:31 is 'undefined' after the mffs instruction.  This value
0xfff80000 just happens to be what populates the high-order word before

Currently fegetenv() will exhibit an undefined high-order word in the
fenv_t.  Likewise we'll be leaving the high-order 32-bits 'undefined' in
the unsigned long long int fpu_control_t.  

I originally tested this on a Power6 with and without -mcpu=power6
specified where the high-order word of the FPSCR register isn't touched
by the two operand mtfsf instruction.  I've learned my lesson and will
make sure to test on completely different hardware next time.

I'll regenerate and verify a clean make check on different classes of
POWER hardware.

Ryan S. Arnold
IBM Linux Technology Center
Linux Toolchain Development

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]