This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix static-binary lazy FPU context allocation
- From: "Ryan S. Arnold" <ryan dot arnold at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, "Maciej W. Rozycki" <macro at codesourcery dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 5 Sep 2013 20:35:55 -0500
- Subject: Re: [PATCH] Fix static-binary lazy FPU context allocation
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 1 dot 10 dot 1308221904520 dot 8514 at tp dot orcam dot me dot uk> <20130822211407 dot GJ20515 at brightrain dot aerifal dot cx> <alpine dot DEB dot 1 dot 10 dot 1308222302050 dot 8514 at tp dot orcam dot me dot uk> <20130822225301 dot GK20515 at brightrain dot aerifal dot cx> <CAAKybw_R5OWKtBiOgMHq-EFejkduEuBBeGX7ctL-1eAu-CV7kw at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1309051949560 dot 367 at digraph dot polyomino dot org dot uk>
On Thu, Sep 5, 2013 at 2:57 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Thu, 5 Sep 2013, Ryan S. Arnold wrote:
>
>> Sort of tangential to the conversation; When I implemented the Decimal
>> Floating Point library I discovered that the IEEE specification
>> (IEEE752-2008) decided to name a set of DFP rounding modes that were
>> only a subset of the actually hardware rounding modes available on
>> Power Architecture hardware. In my library I did see value in
>> allowing a user to set those additional rounding modes as well as the
>> ones defined in the IEEE spec.
>
> That can be done through fe_dec_setround, with extra rounding modes
> defined if __USE_GNU; it doesn't require direct use of __fpu_control or
> _FPU_SETCW.
Looking at the Libdfp code, this is exactly what I did (fe_dec_setround).
> I don't know if you made the DFP library code all work in all of those
> modes (and testcases cover them, etc.). We don't really have any generic
> support for extra binary rounding modes in glibc; if an architecture were
> to add such, we'd need to consider if and how to support them in glibc
> functions and the testsuite. (At least, include/rounding-mode.h would
> need to change for the various bits of code that emulate rounding that
> way, but quite possibly other code wouldn't work in such extra modes
> either.)
The Libdfp test suite isn't yet full-breadth enough to cover all of
the rounding modes. Most of the libdfp code has been checked against
the default DFP rounding mode only.
Ryan
> Generally, users should not necessarily expect glibc functions to work
> correctly in arbitrary floating-point modes outside those that can be set
> with ISO C interfaces (or interfaces in TS 18661 if we support that in
> future, etc.). For example, x86 library functions may not work correctly
> if the x87 precision control is set to 24-bit or 53-bit rather than
> 64-bit.
I agree. In the case of libdfp, rounding mode is the only behavior
modifiable by the user.
Ryan