Re: Fix libm feraiseexcept namespace (bug 17723)

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

On 19-12-2014 16:31, Joseph Myers wrote:
> Various C90 and UNIX98 libm functions call feraiseexcept, which is not
> in those standards.  This causes linknamespace test failures - except
> on x86 / x86_64, where feraiseexcept is inline (for the relevant
> constant arguments) in bits/fenv.h.
>
> This patch fixes this by making those functions call __feraiseexcept
> instead.  All changes are applied to all architectures rather than
> considering the possibility that some might not be needed in some
> cases (e.g. x86) as it seems most maintainable to keep architectures
> consistent.
>
> Where __feraiseexcept does not exist, it is added, with feraiseexcept
> made a weak alias; where it is a strong alias, it is made weak.
> libm_hidden_def / libm_hidden_proto are used with __feraiseexcept
> (this might in some cases improve code generation for existing calls
> to __feraiseexcept in some code on some architectures).  Where there
> are dummy feraiseexcept macros (on architectures without
> floating-point exceptions support, to avoid compile errors from
> references to undefined FE_* macros), corresponding dummy
> __feraiseexcept macros are added.  And on x86, to ensure
> __feraiseexcept calls still get inlined, the inline function in
> bits/fenv.h is refactored so that most of it can be reused in an
> inline __feraiseexcept in a separate include/bits/fenv.h.
>
> Calls are changed in C90/UNIX98 functions, but generally not in
> functions missing from those standards.  They are also changed in
> libc_fe* functions (on the basis that those might be used in any libm
> function), and in feupdateenv (on the same basis - may be used, via
> default libc_*, in any libm function - of course feupdateenv will need
> changing to __feupdateenv in a subsequent patch to make that fully
> namespace-clean).
>
> No __feraiseexcept is added corresponding to the feraiseexcept in
> powerpc bits/fenvinline.h, because that macro definition is
> conditional on !defined __NO_MATH_INLINES, and glibc libm is built
> with -D__NO_MATH_INLINES, so changing internal calls to use
> __feraiseexcept should make no difference.
>
> Tested for x86_64 (testsuite; the only change in disassembly of
> installed shared libraries is a slight code reordering in clog10, of
> no apparent significance).  Also tested for MIPS, where (in the
> configuration tested) it eliminates math.h linknamespace failures for
> n32 and n64 (some for o32 remain because of other issues).
>
> Could someone sanity-check the approach, especially as regards the x86
> inlines, before I commit this?
>
Thanks for the patch, it is ok w.r.t to powerpc.  I checked on powerpc64,
powerp64le, and powerpc32 and it fixes the namespace issues I was seeing
with math.h.