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

Joseph Myers joseph@codesourcery.com
Tue Jun 5 16:32:00 GMT 2018

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) 

(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

More information about the Gcc-patches mailing list