On Fri, Jul 21, 2017 at 03:17:57PM -0400, Michael Meissner wrote: > The first change is to enable the C language to use _Float128 keyword (but not > __float128) without having to use the -mfloat128 option on power7-power9 > systems. My question is in the TR that introduced _Float128, is there any > expectation that outside of the built-in functions we already provide, that we > need to provide runtime functions? Yes, glibc 2.26 will be coming along > shortly, and it should provide most/all of the F128 functions, but distros > won't pick this library up for some time. > > I would like to enable it, but I want to avoid the problem that we have with > __float128 in that once the keyword is supported, it is assumed everything is > supported. GCC and GLIBC run on different cycles (and different people work > on > it), and so you typically have to have GCC add support before GLIBC can use > it. > > We've discovered that boost and libstdc++ both assume the full library support > exists if the __float128 keyword is used. We will eventually need to tackle > both of these libraries, but we need to the full GLIBC support (or > libquadmath) > to provide this functionality.
There isn't much we can do about libraries (or any other code) making bad assumptions. Reducing the pain is the best we can do. > The third change is to add cpu names 'power7f', 'power8f', and 'power9f' that > enable the appropriate power<n> architecture but also does a -mfloat128. The > motavation here is you cannot use either #pragma GCC target anywhere or the > target attribute on the function with a target_clones attribute declaration. Eww. What a horrible hack. Let's please find a sane way to handle this. Float128 is not a feature only some power[789] variants have (and also it could work on *all* targets), it also isn't some specific configuration of the target (like LE is). Segher
