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. 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.) For libstdc++, avoiding multilibs means the same set of mangled names should be present, with the same ABIs, regardless of the default ABI. 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. It is of course possible for different files in libstdc++ to be built with different ABI options (given the existing use of -mno-gnu-attribute for building libstdc++ to avoid this causing linker errors for incompatible ABIs), and for symbols using one mangled name for a given floating-point format to be aliases for symbols using another mangled name for that format. And whereas libstdc++ needs to support long double, whatever type long double is in that particular compilation, it's less clear if it needs to provide much if any support for the other types (although the compiler needs to). The requirement for _Float128 to be different from long double even if they have the same format is a C requirement coming from TS 18661-3. The _FloatN names are deliberately not supported for C++ in GCC, because of an expectation that any C++ binding for types for particular floating-point formats would be class-based, given that was the approach C++ chose for decimal floating point (rather than the C _DecimalN approach). glibc headers do "typedef long double _Float128;" in the C++ case where long double has the correct format, so the distinct _Float128 type is not normally accessible from C++ in that case. However, you *can* access those _FloatN types via typeof and built-in functions, resulting in ICEs for which I've just filed bug 85518. 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)? 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++.) 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). 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. I don't know what if anything GDB would then need to handle the new mangling. -- Joseph S. Myers jos...@codesourcery.com
