On Tue, 5 Jun 2018, Jakub Jelinek wrote: > On Tue, Jun 05, 2018 at 04:08:13PM +0000, Joseph Myers wrote: > > On Tue, 5 Jun 2018, Jakub Jelinek wrote: > > > > > If we need the C separate _FloatNN types in C++, they can mangle the way > > > we > > > (and others) agree on. Would _Float64 be distinct from double and thus > > > mangle differently from "d"? > > > > Right now it (as accessed via __typeof on built-in functions since the > > _FloatN keywords and constant suffixes don't exist in C++) is different > > and results in an ICE (bug 85518). Either it needs to be the same as > > double for C++ (on all architectures, and similarly for _Float32x and all > > the other _FloatN / _FloatNx types with the same format as a standard > > type; and similarly for the _Float64x, _Float128 pair when both are > > distinct from long double, and currently both are distinct from each other > > as well), or else appropriate mangling, presumably DF<number>_, is needed > > for those types (and the ABI would need extending upstream to cover the > > _FloatNx types as well in that case). > > Or guard the builtins on C/ObjC and not C++/ObjC++, e.g. by tweaking > DEF_FLOATN_BUILTIN define somehow.
That could only be done for built-in functions for types that actually have the same format as float / double / long double, and would require additional __cplusplus conditionals in glibc's headers (currently using such conditionals for typedefs, constant suffixes and _Complex versions of these types, but defines of e.g. __builtin_huge_valf64() to (__builtin_huge_val ()) are currently conditioned on !__GNUC_PREREQ (7, 0) only). (Note the logic in those header defines that if double and long double have the same format, maximum compatibility with a distinct _Float64 type means it's better for it to be the same as long double than for it to be the same as double in that case.) -- Joseph S. Myers jos...@codesourcery.com
