[PATCH] D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26

[Szabolcs Nagy via Phabricator via cfe-commits]

nsz added a comment.

In https://reviews.llvm.org/D40673#973638, @efriedma wrote:

> > as this patch is committed clang is broken (cannot use glibc headers)
>
> This patch was supposed to *fix* compatibility with the glibc headers.  If it doesn't, we should clearly revert it... but we need to figure out what we need to do to be compatible first.
>
> From what I can see on this thread, we *must* define _Float128 on x86-64 Linux, and we *must not* define _Float128 for any other glibc target.  Is that correct?  Or does it depend on the glibc version?


it is not clear to me from the original bug report what "fedora 27 workloads" break because of the lack of _Float128 type on x86.  The glibc headers refer to _Float128, but normal include should not break unless the compiler claims to be >=gcc-7 or somebody explicitly requested the _Float128 support.

if clang defines _Float128 then the headers "work" on x86 as in simple math.h include is not broken, but some macro definitions will use the f128 const suffix (e.g. FLT128_MAX) which won't cause much breakage now but in the future users will want to know whether they can use these macros or not.

so either clang have to introduce all these features that are used by glibc together or provide ways for users (and glibc) to figure out what is supported and what isn't.

on non-x86 targets a glibc fix can solve the problem such that they "work" on the same level as x86, i.e. no immediate build breakage on most code, but some features are not supported. i think that's the right way forward, but it's not clear if anybody has time to do the header changes in glibc before release (it has to be tested on several targets).

if glibc is released as is today then those non-x86 targets don't want a _Float128 definition in clang-6 that breaks any math.h include on a glibc-2.27 system.

> (We have a bit of time before the 6.0 release, so we can adjust the behavior here to make it work.  We probably don't want to try to add full _Float128 support on the branch, though.)




Repository:
  rC Clang

https://reviews.llvm.org/D40673