[PATCH] Provide _Float128 for Clang

[H.J. Lu]

On Thu, Dec 19, 2024 at 1:34 AM Joseph Myers <josmyers@redhat.com> wrote:
>
> On Wed, 18 Dec 2024, H.J. Lu wrote:
>
> > Since Clang doesn't provide _Float128:
> >
> > test-fesetexcept-traps.c:67:3: error: unknown type name '_Float128'
> >    67 |   math_force_eval (b);
> >       |   ^
> > ../sysdeps/x86/fpu/math-barriers.h:34:49: note: expanded from macro 'math_force_eval'
> >    34 |         || __builtin_types_compatible_p (__typeof (x), _Float128))      \
> >       |                                                        ^
> >
> > provide it for Clang.
>
> The correct place for compatibility definitions for _Float128 is
> bits/floatn.h (an installed header) - for x86, that's
> sysdeps/x86/bits/floatn.h.
>
> That header already knows about older GCC supporting __float128 but not
> _Float128 and has appropriate conditionals to use that support (including
> corresponding definitions of __CFLOAT128, __builtin_huge_valf128, etc. as
> needed).  So what should be done is to add appropriate Clang conditionals
> to that header, then ensure it's included anywhere it's needed internally
> in glibc.
>
> As a starting point, see the "x86: Define __HAVE_FLOAT128 for Clang and
> use __builtin_*f128 code path" commit in the azanella/clang branch

Thanks for the pointer.

> (actually, that branch should be a starting point for all Clang-related
> fixes - sometimes the patches in it may not follow a good approach for
> inclusion in glibc, but it's still worth checking what that branch does
> for an issue before developing your own patch if you disagree with the one
> in that branch).

I don't think Clang can be used to compile glibc easily.  One problem is
that Clang has its own copy of <float.h> and <tgmath.h>.  It doesn't use
<float.h> and <tgmath.h> from glibc.  My goal is to test glibc with Clang,
not build glibc with Clang.  My current test results are:

FAIL: conform/ISO11/inttypes.h/conform
FAIL: conform/ISO11/stdint.h/conform
FAIL: conform/ISO11/tgmath.h/conform
FAIL: conform/ISO99/inttypes.h/conform
FAIL: conform/ISO99/stdint.h/conform
FAIL: conform/ISO99/tgmath.h/conform
FAIL: conform/POSIX2008/inttypes.h/conform
FAIL: conform/POSIX2008/stdint.h/conform
FAIL: conform/POSIX2008/tgmath.h/conform
FAIL: conform/XOPEN2K/inttypes.h/conform
FAIL: conform/XOPEN2K/stdint.h/conform
FAIL: conform/XOPEN2K/tgmath.h/conform
FAIL: conform/XOPEN2K8/inttypes.h/conform
FAIL: conform/XOPEN2K8/stdint.h/conform
FAIL: conform/XOPEN2K8/tgmath.h/conform
FAIL: debug/tst-ssp-1
FAIL: elf/ifuncmain1picstatic
FAIL: elf/ifuncmain1static
FAIL: elf/ifuncmain2picstatic
FAIL: elf/ifuncmain2static
FAIL: elf/ifuncmain4
FAIL: elf/ifuncmain4picstatic
FAIL: elf/ifuncmain4static
FAIL: elf/ifuncmain5picstatic
FAIL: elf/ifuncmain5static
FAIL: elf/ifuncmain6pie
FAIL: elf/ifuncmain7
FAIL: elf/ifuncmain7pic
FAIL: elf/ifuncmain7picstatic
FAIL: elf/ifuncmain7pie
FAIL: elf/ifuncmain7static
FAIL: elf/tst-dlopen-nodelete-reloc
FAIL: math/test-tgmath
FAIL: math/test-tgmath2
FAIL: stdio-common/tst-vfprintf-user-type

We should exam every failure after all my patches have been
committed.

> The patch in that branch is only a starting point, probably not ready for
> inclusion as is, because it doesn't have any Clang version conditionals.
> Since bits/floatn.h is an installed header, Clang support changes there
> should handle *all* released Clang versions that supported relevant glibc
> targets.  So unless every Clang release supporting glibc's x86 targets
> also supported __float128 on those targets (and likewise for built-in
> function etc. conditionals in the header as well), some Clang version
> conditionals are needed as well.  But once you've checked what Clang
> versions supported __float128 and related features, something based on
> that branch can be used to add that information to bits/floatn.h, which
> should solve your problem.  (Of course other architectures might need
> their own changes to their own bits/floatn.h files, but those could be
> dealt with separately.)
>
> --
> Joseph S. Myers
> josmyers@redhat.com
>


--
H.J.