Re: Make powerpc-nofpu floating-point state thread-local (bug 15483)

[Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>]

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
> thread-local.
>
> This patch depends on my previous patch
> <https://sourceware.org/ml/libc-alpha/2013-11/msg00180.html> to add
> libc_hidden_tls_proto.
>
> 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).