This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Add _Float128 function aliases [committed]
On Tue, 9 Jan 2018, Szabolcs Nagy wrote:
> On 09/01/18 16:47, Joseph Myers wrote:
> > On Tue, 9 Jan 2018, Szabolcs Nagy wrote:
> >
> >> note that this typedef in a public header does not work
> >> on compilers that support _Float128 but not >=gcc-7
> >
> > It's entirely appropriate to add support for other compilers in
> > bits/floatn.h headers (there are several bits/floatn.h variants in glibc -
> > if it's a matter of "clang version N supports _Float128 on this set of
> > configurations", the headers used by those configurations are the ones
> > appropriate to update), where those compilers have some form of _FloatN /
> > _FloatNx / __float128 support that could reasonably be used with installed
> > glibc headers.
> >
>
> i can provide a workaround in aarch64 target specific
> headers, but i think this is should be fixed in
> sysdeps/ieee754/ldbl-128/bits/floatn.h
>
> maybe check for __FLT128_MANT_DIG==113 instead of gcc-7?
> clang defines this macro too.
Sure, that would be appropriate (in conjunction with the existing
__cplusplus tests - GCC defines __FLT128_MANT_DIG for C++ without
supporting the _Float128 type name or constant suffixes in that case), if
clang versions / configurations supporting _Float128 define
__FLT128_MANT_DIG while those not supporting _Float128 don't.
That would seem appropriate for all bits/floatn.h headers with any
_Float128 support (subject to being accurate for each thing being
conditioned - some __GNUC_PREREQ conditionals are for uses of f128
constant suffixes, or __builtin_*f128 built-in functions, so you should
make sure those features are supported by relevant clang versions), not
just the ldbl-128 version.
--
Joseph S. Myers
joseph@codesourcery.com