This is the mail archive of the
mailing list for the glibc project.
Re: Make powerpc-nofpu floating-point state thread-local (bug 15483)
- From: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Cc: Alexandre Oliva <aoliva at redhat dot com>
- Date: Tue, 19 Nov 2013 09:46:15 -0200
- Subject: Re: Make powerpc-nofpu floating-point state thread-local (bug 15483)
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1311072103050 dot 15899 at digraph dot polyomino dot org dot uk> <528B4F56 dot 4030702 at linux dot vnet dot ibm dot com>
Just clarifying, I checked with dependent patch applied.
On 19-11-2013 09:45, Adhemerval Zanella wrote:
> This patch is ok, thanks.
> On 07-11-2013 19:05, Joseph S. Myers wrote:
>> This patch fixes bug 15483, powerpc-nofpu floating-point state being
>> wrongly global instead of thread-local. The relevant state is moved
>> to TLS variables, with the old global variables becoming compat
>> symbols not available for new links, and being updated when the TLS
>> variables are updated, but never read by libc; I think this is the
>> most ABI-compatible option available for making this data
>> thread-local. (Static libc doesn't have the old global variables at
>> all.) An architecture-independent test is added for this data being
>> This patch depends on my previous patch
>> <https://sourceware.org/ml/libc-alpha/2013-11/msg00180.html> to add
>> Tested for powerpc-nofpu, and the new test also tested for x86_64.
>> There are legitimate uses for compiler-generated code to access some
>> of this state without introducing a libm dependency. To facilitate
>> those, I intend in a future patch to add new interfaces __flt_rounds,
>> __atomic_feholdexcept, __atomic_feclearexcept and __atomic_feupdateenv
>> to powerpc-nofpu libc. The first could be used in fixing GCC bug
>> 30569 (for most platforms, inline code examining FPU state can
>> determine the rounding mode, but not where the rounding mode is a
>> variable in libc as here) and the remaining three in implementing the
>> new TARGET_ATOMIC_ASSIGN_EXPAND_FENV target hook (in the latter case,
>> e500 GCC will need them as well as pure soft-float, because of the
>> prctl syscalls involved in environment manipulation - of course all
>> four functions will be implemented for both soft-float and e500 to
>> keep the ABIs the same).