Re: [PATCH], Add weak references to bridge old/new PowerPC ieee 128-bit name mangling

[Joseph Myers <joseph at codesourcery dot com>]

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
joseph@codesourcery.com