On Tue, Apr 24, 2018 at 05:42:39PM +0000, Joseph Myers wrote: > On Mon, 16 Apr 2018, Segher Boessenkool wrote: > > > > The manglings that are now used are: > > > > > > For -mabi=ieeelongdouble: > > > > > > __float128 "u10__float128" > > > __ibm128 "u8__ibm128" > > > long double "u9__ieee128" > > > > > > For -mabi=ibmlongdouble: > > > > > > __float128 "u10__float128" > > > __ibm128 "u8__ibm128" > > > long double "g" > > > > > > For -mlong-double-64: > > > > > > __float128 "u10__float128" > > > __ibm128 "u8__ibm128" > > > long double "e" > > > > If __float128 is the same type as _Float128, as which of those should > > it be mangled? The C++ ABI has "DF" for _FloatN, but the demangler uses > > that same code for fixed points types. Ugh. > > > > I don't think mangling "long double" as "u9__ieee128" works well with for > > example GDB. > > > > Cc:ing Joseph Myers; Joseph, do you have any advice here? > > I believe it has been stated that the goal is for IEEE long double not to > require separate multilibs of GCC's libraries; that is, for both libgcc > and libstdc++ to provide all the required functions under appropriate > names, whichever is the default when GCC is built, and for the right > functions to be used automatically.
Yes, as long as no incompatible ABI is required, and that is part of why currently ieee128 is only supported on systems with VSX. Supporting it on other systems sould be akin to soft float. > For libgcc, this is achieved by the existing *tf* names continuing to be > bound to IBM long double, and new *kf* names being used for IEEE long > double. (I don't know if the correct functions now get built for both > choices of the default ABI - i.e. all *tf* functions, including those from > libgcc2.c, always being built for IBM long double even when TFmode is IEEE > long double, all *kf* functions always being built for IEEE long double, > and the compiler always generating calls to the correct functions for > IFmode, KFmode and TFmode, whichever format TFmode has. But if there are > any remaining issues in this area, they are orthogonal to the C++ issues.) I checked, and it seems to work correctly. > For libstdc++, avoiding multilibs means the same set of mangled names > should be present, with the same ABIs, regardless of the default ABI. Yes. > This is why, for example, the existing IBM long double uses "g" rather > than "e" (the normal long double mangling) - because when long double > originally had the same ABI as double, that meant "e" symbols were used > for that 64-bit long double. So we need a new mangling for IEEE 128-bit float. Mangling it the same as the "__ieee128" type is probably going to cause problems, and at the very least it is a confusing name. (The demangler shows "e" as "long double", but it shows "g" as "__float128", which is wrong; adding "__ieee128" to the mix will not help). > Returning to the long double, __ibm128 and __float128 types, I suppose > there are questions: > > * Which types need to be different types at the C++ language level? If > people do want to use these types in templates and overloads, I suppose > that indicates always having three separate types as you suggest. > > * Where does __ieee128 fit in? > > * Where does __typeof (__builtin_inff128 ()) (GCC's internal _Float128 > type, cf. bug 85518) fit in? > > * What is the mangling for all those types? > > * Which types are supported by libstdc++ (in that it's valid to use them > as arguments to libstdc++ functions / templates)? > > * Which function names are provided by libstdc++ (possibly as aliases)? Yes, lots of questions :-( > The "DF<number>_" mangling was introduced to distinguish _Float16 from > __fp16, see <https://github.com/itanium-cxx-abi/cxx-abi/issues/21>. *If* > it were decided to address bug 85518 by generically supporting mangling > for the not-quite-hidden-for-C++ _FloatN types (as opposed to arranging > for float64_type_node etc. to actually be copies of double etc. for C++, > or for the types to otherwise be completely hidden), I suppose it would be > natural to use that mangling for those types - but the C++ ABI would need > to be extended to cover _FloatNx as well if that bug is to be completely > fixed that way. (And this ignores the fixed-point issue - I don't know > why that support is in the demangler, since we don't support fixed-point > for C++, though I suppose mode attributes might allow fixed-point to creep > into C++ code anyway - bug 39059 was constants formerly allowing them into > C++.) And another, in generic code. > As I understand the proposed patch, it would mean __float128 and __ieee128 > are always aliases for the not-quite-hidden _Float128 type. In that case, > generic DF128_ mangling would apply to those. __ibm128, being always > different from long double after the patch, would then have u8__ibm128 > mangling as suggested. Making __float128 always different from long > double would mean *some* different mangling for IEEE long double would be > needed (which would not be the same as the _Float128 mangling). Agreed on all these. > Then libstdc++ would need to contain, independent of the default ABI used > by the compiler, the "e" functions (aliases / wrappers for "d" ones), the > "g" functions (existing IBM long double functions), and functions for the > new mangling for IEEE long double. It might or might not have functions / > aliases (and typeinfo etc.) that can be used for __ibm128 or __float128. Yup. > I don't know what if anything GDB would then need to handle the new > mangling. (This is primarily a demangler problem). If there are different manglings for long double, GDB should be able to distinguish between them some way. Not that people have seemed to mind so far. But at least the demangled names should make sense: "g" is "long double", but it shows as "__float128", which is a different type, with a different representation too (depending on options). Segher
