On Tue, Oct 23, 2018 at 10:22:41PM +0000, Joseph Myers wrote:
> On Tue, 23 Oct 2018, Michael Meissner wrote:
> 
> > 2018-10-23  Michael Meissner  <meiss...@linux.ibm.com>
> > 
> >     * config/rs6000/rs6000.c (TARGET_MANGLE_DECL_ASSEMBLER_NAME):
> >     Define as rs6000_mangle_decl_assembler_name.
> >     (rs6000_mangle_decl_assembler_name): If the user switched from IBM
> >     long double to IEEE long double, switch the names of the long
> >     double built-in functions to be <func>f128 instead of <func>l.
> 
> [This is the issue discussed at the Cauldron of how to get the 
> redirections correct in any case that does not involve including the 
> standard <math.h> to get the function declarations.]
> 
> My understanding was that __<func>ieee128 aliases would be added to glibc 
> (indeed, the relevant names are present in 
> sysdeps/ieee754/ldbl-128ibm-compat/Versions in glibc, albeit without 
> actually being enabled for powerpc64le yet), for two reasons: (a) to be 
> namespace-clean for standard C, and (b) because a few libm functions (and 
> many libc functions) have no _Float128 analogues but are still part of the 
> API for long double (e.g. the nexttoward functions, where nexttowardf, 
> nexttoward also need different versions for IEEE 128-bit long double, or 
> scalbl, which is somewhat obsolescent but still supported).
> 
> Now, you can't use the __<func>ieee128 names with *current* glibc because 
> they aren't exported yet.  So is the plan that GCC would later switch to 
> using the __<func>ieee128 names when available based on TARGET_GLIBC_MAJOR 
> and TARGET_GLIBC_MINOR (as more namespace-correct, and available for some 
> functions without <func>f128 variants), with use of <func>f128 only a 
> fallback for older glibc versions lacking __<func>ieee128?

I suspect the timing may not be right for GCC 9, since I tend to use the
Advance Toolchain to get newer glibc's, and they are on 2.28.  I just tried it,
and as you said, they aren't exported yet.

However, I am somewhat relunctant to do patches if I don't have a glibc that
properly exports them.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Reply via email to