This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/6411] PowerPC: Extend fpu fenv operations to operate on 64-bit FPSCR
- From: "rsa at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 13 Aug 2008 04:49:56 -0000
- Subject: [Bug libc/6411] PowerPC: Extend fpu fenv operations to operate on 64-bit FPSCR
- References: <20080415211350.6411.rsa@us.ibm.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From rsa at us dot ibm dot com 2008-08-13 04:49 -------
(In reply to comment #3)
> You're changing an exported type. That's not possible. You have to find
> another way. From what I have seen there are only a few bits of the
> fpu_control_t used. There is no reason why this type must exactly correspond to
> the values you get from the control register.
I understand your argument but I can't find any published information which
would indicate that there is anything but a 1:1 correspondence between the
fpu_control_t and the FPSCR's bits.
Is the intention of the fpu_control_t to only allow users to get (and in some
cases set) the values that correspond to the published masks, i.e. just rounding
control masks and some exception status?
If this is the case then I'll just use some bits that correspond to the 32-bit
FPSCR's exception enable bits that are marked 'reserved' in fpu_control.h for
the DRN (Decimal Rounding control bits).
> On the formatting: indent all the preprocessor directives correctly (i.e., add
> spaces after the initial #).
OK.
Thanks for the review.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |ASSIGNED
Last reconfirmed|0000-00-00 00:00:00 |2008-08-13 04:49:55
date| |
http://sourceware.org/bugzilla/show_bug.cgi?id=6411
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.