Changes to allow PowerPC to change the long double type to use the IEEE 128-bit floating point format

Changes to allow PowerPC to change the long double type to use the IEEE 128-bit floating point format

[Michael Meissner]

I want to discuss changes that I think we need to make across the open source
toochain to allow us to change the long double type on PowerPC hardware from
using the IBM extended double (i.e. a pair of doubles) to the IEEE 128-bit
format defined in IEEE 754.

I wasn't sure whom to address this to, so I took a scatter shot approach.  I
likely missed a few people, and some people were added that may not need to
participate in the discussion.  Sorry for either not including you initially or
for including you by mistake.

I added people from the following areas:

	PowerPC folk

	Langugage maintainers: At the moment, only the C/C++ front ends have
	code to support both 128-bit floating point types.  The other languages
	use just the defaults provided by the machine maintainers.  However, it
	may be we will need to think about rules for code being compiled and
	linked with a different long double format.

	Arm/x86 maintainers: It is possible that these sorts of changes might
	mesh with things that are being planned.  For example, maybe x86 might
	want to explore changing the default for long double from the
	traditional Intel 80-bit format to IEEE 128-bit.  And there might be
	issues with the several different 16-bit floating point formats
	floating around.

	Glibc developers: I added Tulio and Carlos, but I suspect there may be
	others that might want to respond.

	Binutils developers: I added Alan, Peter, and Nick.  I don't know who
	else might be interested.

	Gdb developers: I added Pedro and Ulrich, but I don't know if there are
	others that may be interested.

At the moment, this change is only done if you use the following option:
	--with-long-double-format=ieee

option when configuring GCC.  There will be some changes need to make this
option work as intended.  You will also need an up to date glibc and binutils
if you want to use this option.

In terms of time table, I feel that whatever changes are made NEED to be done
by the time GCC 11 is released.

Each topic will be done as a followup to this post, so that people can
concentrate on individual features via threaded email readers, rather than
wading through the whole list over time.

For those of you that are not aware, the PowerPC ISA 3.0 (power9) now has
instructions that implement IEEE 754 128-bit floating point directly.  Over the
last few releases, I have been adding support for IEEE 128-bit floating point
into GCC.  On power7 and power8 hardware we use soft-float emulator to emulate
the IEEE 128-bit floating point format.

At the moment, we are only considering doing these changes on the little endian
PowerPC linux systems.

In theory, it could work on big endian 64-bit PowerPC linux systems that are
configured with a minimum cpu of power7.  You would need to edit the libgcc and
gcc support to enable IEEE 128-bit floating point on those systems and build
current glibc for those systems.  However, I'm not planning to do this work.

In addition, the IEEE 128-bit instructions are not enabled on 32-bit systems
(you can use the soft-fp emulation, just not the hardware support).  This is
due to the issue within GCC we don't support TImode on 32-bit systems.  Some
parts of GCC require a supported integer that is the same size as basic types.
If somebody is motivated to do that work, that is fine, but I'm not planning to
do that work.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797

PowerPC long double Mangling

[Michael Meissner]

One issue with doing the transition is what mangling should be used with the
new long double.

At the moment, the current mangling is:
	long double	"g"
	__float128	"u9__ieee128"
	__ibm128	"g"

Obviously this will have to change in the future.  It is unfortunate that we
choose "g" to mean IBM extended double many many years ago, when it should have
been used for IEEE 128-bit floating point.  But that is long ago, so I think we
need to keep it.

But assuming we want compatibility with libraries like glibc and libstdc++, I
think we will have to continue to use "g" for __ibm128.

With the long double change, I tend to view this as an ABI change.  But if the
user doesn't use long double, they should be able to link without changes.

I would propose using a new mangling for IEEE 128-bit long double.  I would
prefer to get agreement on what the new mangling should be so we don't have an
issue like we had in GCC 8.1 going to GCC 8.2, where we changed the mangling,
and had to provide aliases for the old name.

At the moment I think the mangling should be:
	long double	"g"			if long double is IBM
	long double	"u12_ieee128_ld"	if long double is IEEE
	__float128	"u9__ieee128"
	__ibm128	"g"

If we decide to change the __ibm128 mangling (or the long double when long
double is IBM), then we will likely need to generate aliases to bridge the old
vs. new support.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797

Re: PowerPC long double Mangling

[Jonathan Wakely]

Sorry for the slow reply to this.

On Fri, 7 Aug 2020 at 22:14, Michael Meissner <meissner@linux.ibm.com> wrote:
>
> One issue with doing the transition is what mangling should be used with the
> new long double.
>
> At the moment, the current mangling is:
>         long double     "g"
>         __float128      "u9__ieee128"
>         __ibm128        "g"
>
> Obviously this will have to change in the future.  It is unfortunate that we
> choose "g" to mean IBM extended double many many years ago, when it should have
> been used for IEEE 128-bit floating point.  But that is long ago, so I think we
> need to keep it.
>
> But assuming we want compatibility with libraries like glibc and libstdc++, I
> think we will have to continue to use "g" for __ibm128.
>
> With the long double change, I tend to view this as an ABI change.  But if the
> user doesn't use long double, they should be able to link without changes.
>
> I would propose using a new mangling for IEEE 128-bit long double.  I would
> prefer to get agreement on what the new mangling should be so we don't have an
> issue like we had in GCC 8.1 going to GCC 8.2, where we changed the mangling,
> and had to provide aliases for the old name.
>
> At the moment I think the mangling should be:
>         long double     "g"                     if long double is IBM
>         long double     "u12_ieee128_ld"        if long double is IEEE
>         __float128      "u9__ieee128"
>         __ibm128        "g"

What's the benefit of having __float128 and IEEE long double be
distinct types? That complicates things for libraries like libstdc++.
If we want to support using "__float128" with C++ iostreams then we
need yet another set of I/O routines, even though it's identical to
one of the types we already handle. Why not just keep __float128 and
__ieee128 and "long double when long double is IEEE" as three
different aliases for the same type, so that C++ code like
_Z4funcu9__ieee128 works for all of them, instead of needing to also
define _Z4funcu12__ieee128_ld?

What about the "__ieee128" type, would that be mangled as
"u12_ieee128_ld" or "u9__ieee128"?

Currently it's the latter, i.e. __ieee128 is the same type as
__float128, which is the same type as "long double when
-mabi=ieeelongdouble". That seems useful to me, because it means that
I can always use either __ibm128 or __ieee128 to refer to "the type
that is sometimes known as 'long double'" irrespective of which -mabi
is actually used.

Today's mangling means I can declare a function in a header file as:

void func(long double);

and then in a library provide two definitions of that function, with
the right one being chosen by the linker depending what mangled name
it uses for "func(long double)" e.g. the definitions would be:

void func(__ibm128) { }
void func(__ieee128) { }

If __ieee128 is mangled to u9__ieee128, then if you compile the header
with -mabi=ieeelongdouble you can't link to the definition. To make it
work with the proposed mangling, the definitions would have to be:

void func(__ibm128) { }
void func(long double) { }

and then using -mabi=ieeelongdouble to compile the file would be
mandatory. That isn't terrible, but it seems inconsistent and
asymmetrical.

I'd also find it surprising if __ieee128 is not mangled to u9__ieee128
since that's its name :-) But that's far less important than the
practical matter of which types are mangled to the same and which
overloads are equivalent to each other.

Re: PowerPC long double Mangling

[Segher Boessenkool]

Hi!

On Wed, Sep 09, 2020 at 02:42:36PM +0100, Jonathan Wakely wrote:
> On Fri, 7 Aug 2020 at 22:14, Michael Meissner <meissner@linux.ibm.com> wrote:
> > But assuming we want compatibility with libraries like glibc and libstdc++, I
> > think we will have to continue to use "g" for __ibm128.

Yes.

> > With the long double change, I tend to view this as an ABI change.

You can use both __ibm128 and __ieee128 in one program, so it isn't an
ABI change.  Only the default of what "long double" means changes.  And
we have been there before, there is the "e" mangling as well...

> > I would propose using a new mangling for IEEE 128-bit long double.  I would
> > prefer to get agreement on what the new mangling should be so we don't have an
> > issue like we had in GCC 8.1 going to GCC 8.2, where we changed the mangling,
> > and had to provide aliases for the old name.
> >
> > At the moment I think the mangling should be:
> >         long double     "g"                     if long double is IBM
> >         long double     "u12_ieee128_ld"        if long double is IEEE

Why?  Why can't this be exactly the same as __ieee128?

> >         __float128      "u9__ieee128"
> >         __ibm128        "g"

(There is DF128_ as well btw, oh joy).

> What's the benefit of having __float128 and IEEE long double be
> distinct types? That complicates things for libraries like libstdc++.

Yeah.

> If we want to support using "__float128" with C++ iostreams then we
> need yet another set of I/O routines, even though it's identical to
> one of the types we already handle. Why not just keep __float128 and
> __ieee128 and "long double when long double is IEEE" as three
> different aliases for the same type, so that C++ code like
> _Z4funcu9__ieee128 works for all of them, instead of needing to also
> define _Z4funcu12__ieee128_ld?

Both __ieee128 and __float128 are in the implementation namespace, so
we can do whatever we want with it, indeed.

> What about the "__ieee128" type, would that be mangled as
> "u12_ieee128_ld" or "u9__ieee128"?

The latter.  Anything else would be an ABI change.

> Currently it's the latter, i.e. __ieee128 is the same type as
> __float128, which is the same type as "long double when
> -mabi=ieeelongdouble". That seems useful to me, because it means that
> I can always use either __ibm128 or __ieee128 to refer to "the type
> that is sometimes known as 'long double'" irrespective of which -mabi
> is actually used.

Yes.

> I'd also find it surprising if __ieee128 is not mangled to u9__ieee128
> since that's its name :-) But that's far less important than the
> practical matter of which types are mangled to the same and which
> overloads are equivalent to each other.

Mangling to u12__ieee_128_ld means we have a type named __ieee128_ld.
We don't.


Segher

Re: PowerPC long double Mangling

[Thomas Koenig]

Am 09.09.20 um 17:36 schrieb Segher Boessenkool:
> You can use both __ibm128 and __ieee128 in one program, so it isn't an
> ABI change.  Only the default of what "long double" means changes.  And
> we have been there before, there is the "e" mangling as well...

For Fortran, it is an ABI change unless we define an additional KIND
number for __ieee128.

Best regards

	Thomas

Re: PowerPC long double Mangling

[Segher Boessenkool]

On Wed, Sep 09, 2020 at 07:06:41PM +0200, Thomas Koenig wrote:
> Am 09.09.20 um 17:36 schrieb Segher Boessenkool:
> >You can use both __ibm128 and __ieee128 in one program, so it isn't an
> >ABI change.  Only the default of what "long double" means changes.  And
> >we have been there before, there is the "e" mangling as well...
> 
> For Fortran, it is an ABI change unless we define an additional KIND
> number for __ieee128.

Yes, Fortran has existing problems here (now *already*).


Segher

Re: PowerPC long double Mangling

[Jakub Jelinek]

On Wed, Sep 09, 2020 at 12:32:22PM -0500, Segher Boessenkool wrote:
> On Wed, Sep 09, 2020 at 07:06:41PM +0200, Thomas Koenig wrote:
> > Am 09.09.20 um 17:36 schrieb Segher Boessenkool:
> > >You can use both __ibm128 and __ieee128 in one program, so it isn't an
> > >ABI change.  Only the default of what "long double" means changes.  And
> > >we have been there before, there is the "e" mangling as well...
> > 
> > For Fortran, it is an ABI change unless we define an additional KIND
> > number for __ieee128.
> 
> Yes, Fortran has existing problems here (now *already*).

Well, the Fortran kind case is the same thing as the change of the meaning
of long double from __ibm128 to __ieee128.
Neither C nor Fortran has special mangling for that, so for those languages
it is a real ABI change, for C++ it is an ABI change too, but one that can
be dealt for selected libraries through mangling and compiling stuff that
refers to long double twice (e.g. libstdc++).  For glibc I guess it can be
dealt with using asm redirects of the math functions.

	Jakub

Re: PowerPC long double Mangling

[Segher Boessenkool]

On Wed, Sep 09, 2020 at 07:41:02PM +0200, Jakub Jelinek wrote:
> On Wed, Sep 09, 2020 at 12:32:22PM -0500, Segher Boessenkool wrote:
> > On Wed, Sep 09, 2020 at 07:06:41PM +0200, Thomas Koenig wrote:
> > > Am 09.09.20 um 17:36 schrieb Segher Boessenkool:
> > > >You can use both __ibm128 and __ieee128 in one program, so it isn't an
> > > >ABI change.  Only the default of what "long double" means changes.  And
> > > >we have been there before, there is the "e" mangling as well...
> > > 
> > > For Fortran, it is an ABI change unless we define an additional KIND
> > > number for __ieee128.
> > 
> > Yes, Fortran has existing problems here (now *already*).
> 
> Well, the Fortran kind case is the same thing as the change of the meaning
> of long double from __ibm128 to __ieee128.
> Neither C nor Fortran has special mangling for that, so for those languages
> it is a real ABI change, for C++ it is an ABI change too, but one that can
> be dealt for selected libraries through mangling and compiling stuff that
> refers to long double twice (e.g. libstdc++).  For glibc I guess it can be
> dealt with using asm redirects of the math functions.

My point is that you already have *both* __ibm128 and __ieee128, and you
can have them in one source file even, and that just works.  In C.

Which of those some configuration uses by default matters a lot for libs
that use long double of course, but there is an ELF attribute for that,
so problems are not hard to spot usually.

But for Fortran this still does not work at all.


Segher

Re: PowerPC long double Mangling

[Michael Meissner]

On Wed, Sep 09, 2020 at 02:42:36PM +0100, Jonathan Wakely wrote:
> Sorry for the slow reply to this.
> 
> On Fri, 7 Aug 2020 at 22:14, Michael Meissner <meissner@linux.ibm.com> wrote:
> >
> > One issue with doing the transition is what mangling should be used with the
> > new long double.
> >
> > At the moment, the current mangling is:
> >         long double     "g"
> >         __float128      "u9__ieee128"
> >         __ibm128        "g"
> >
> > Obviously this will have to change in the future.  It is unfortunate that we
> > choose "g" to mean IBM extended double many many years ago, when it should have
> > been used for IEEE 128-bit floating point.  But that is long ago, so I think we
> > need to keep it.
> >
> > But assuming we want compatibility with libraries like glibc and libstdc++, I
> > think we will have to continue to use "g" for __ibm128.
> >
> > With the long double change, I tend to view this as an ABI change.  But if the
> > user doesn't use long double, they should be able to link without changes.
> >
> > I would propose using a new mangling for IEEE 128-bit long double.  I would
> > prefer to get agreement on what the new mangling should be so we don't have an
> > issue like we had in GCC 8.1 going to GCC 8.2, where we changed the mangling,
> > and had to provide aliases for the old name.
> >
> > At the moment I think the mangling should be:
> >         long double     "g"                     if long double is IBM
> >         long double     "u12_ieee128_ld"        if long double is IEEE
> >         __float128      "u9__ieee128"
> >         __ibm128        "g"
> 
> What's the benefit of having __float128 and IEEE long double be
> distinct types? That complicates things for libraries like libstdc++.
> If we want to support using "__float128" with C++ iostreams then we
> need yet another set of I/O routines, even though it's identical to
> one of the types we already handle. Why not just keep __float128 and
> __ieee128 and "long double when long double is IEEE" as three
> different aliases for the same type, so that C++ code like
> _Z4funcu9__ieee128 works for all of them, instead of needing to also
> define _Z4funcu12__ieee128_ld?

The Boost library has methods that have both long double and __float128 in it.
My main concern is not to break user code like Boost that the users may added
__float128.  Obviously with glibc and libstdc++ we have people who understand
the issues, but who knows what other libraries people have come up with.

So if we configure long double to be IEEE 128-bit, under the current code it
would be an error.  Consider this silly code.  Yes it likely would be a
template, but the issue is if the user mixes __float128 and long double, is it
an error if long double has the same representation as IEEE 128-bit:

	class foo {
	public:
	  double add (double a, double b) { return a+b; }
	  long double add (long double a, long double b) { return a+b; }
	  __float128 add (__float128 a, __float128 b) { return a+b; }
	};

	foo x;

	__float128
	bletch_f128 (__float128 a, __float128 b)
	{
	  return x.add (a, b);
	}

	long double
	bletch_ld (long double a, long double b)
	{
	  return x.add (a, b);
	}

If we compile this with the current compiler, it compiles fine if long double
uses the IBM extended double.

But if we compile it with -Wno-psabi -mabi=ieeelongdouble, we get:

	In file included from foo-class.cpp:1:
	foo-class.h:5:14: error: ‘long double foo::add(long double, long double)’ cannot be overloaded with ‘long double foo::add(long double, long double)’
	    5 |   __float128 add (__float128 a, __float128 b) { return a+b; }
	      |              ^~~
	foo-class.h:4:15: note: previous declaration ‘long double foo::add(long double, long double)’
	    4 |   long double add (long double a, long double b) { return a+b; }
	      |               ^~~

Because right now the compiler only has two types, whatever long double is, and
whatever is not long double.  You have the same issue right now with __ibm128
and the current long double, but I'm not convinced anybody outside of glibc and
libstdc++ really uses it.

Since people do use __float128, since the x86_64 port supports it, it is an
issue.

If you use the -mlong-double-128 option on the X86_64 compiler, you get an
error, though in this case it is a more cryptic error message (compiler used
was a 10.2 compiler):

	foo-class.cpp:15:1: error: Two symbols with same comdat_group are not linked by the same_comdat_group list.
	   15 | }
	      | ^
	_ZN3foo3addEgg/2 (__float128 foo::add(__float128, __float128)) @0x7f0068b922d0
	  Type: function definition analyzed
	  Visibility: public weak comdat comdat_group:_ZN3foo3addEgg one_only
	  previous sharing asm name: 1
	  References: 
	  Referring: 
	  Function flags: body
	  Called by: _Z7bletch1gg/4 
	  Calls: 
	_ZN3foo3addEgg/1 (long double foo::add(long double, long double)) @0x7f0068b92168
	  Type: function definition analyzed
	  Visibility: public weak comdat comdat_group:_ZN3foo3addEgg one_only
	  next sharing asm name: 2
	  References: 
	  Referring: 
	  Function flags: body
	  Called by: _Z7bletch2gg/5 
	  Calls: 
	foo-class.cpp:15:1: internal compiler error: symtab_node::verify failed
	0xb9f9d9 symtab_node::verify_symtab_nodes()
		/home/meissner/fsf-src/gcc-10.2.0/gcc/symtab.c:1354
	0xbb2444 symtab_node::checking_verify_symtab_nodes()
		/home/meissner/fsf-src/gcc-10.2.0/gcc/cgraph.h:667
	0xbb2444 symbol_table::compile()
		/home/meissner/fsf-src/gcc-10.2.0/gcc/cgraphunit.c:2738
	0xbb450c symbol_table::compile()
		/home/meissner/fsf-src/gcc-10.2.0/gcc/cgraphunit.c:2735
	0xbb450c symbol_table::finalize_compilation_unit()
		/home/meissner/fsf-src/gcc-10.2.0/gcc/cgraphunit.


> What about the "__ieee128" type, would that be mangled as
> "u12_ieee128_ld" or "u9__ieee128"?

Please use __float128 and not __ieee128 in public code.  The user visible
keyword is __float128, not __ieee128.

Internally within the compiler, the real keyword is __ieee128, and there is a
macro '__float128'.  This uglyness was needed in previous compilers to allow
disabling __float128 as a public keyword, but to allow the libraries to still
use it (due to Boost's usage of __float128).


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797

Re: PowerPC long double Mangling

[Jakub Jelinek]

On Tue, Sep 15, 2020 at 01:37:20AM -0400, Michael Meissner wrote:
> > What's the benefit of having __float128 and IEEE long double be
> > distinct types? That complicates things for libraries like libstdc++.
> > If we want to support using "__float128" with C++ iostreams then we
> > need yet another set of I/O routines, even though it's identical to
> > one of the types we already handle. Why not just keep __float128 and
> > __ieee128 and "long double when long double is IEEE" as three
> > different aliases for the same type, so that C++ code like
> > _Z4funcu9__ieee128 works for all of them, instead of needing to also
> > define _Z4funcu12__ieee128_ld?
> 
> The Boost library has methods that have both long double and __float128 in it.
> My main concern is not to break user code like Boost that the users may added
> __float128.  Obviously with glibc and libstdc++ we have people who understand
> the issues, but who knows what other libraries people have come up with.

So it will need some changes, we can describe what needs to change in
gcc-11/porting_to.html.  Boost already needs code not to enable it if
__float128 doesn't exist, so the condition would just change to __float128
does not exist or long double is the same thing (e.g. mangles the same) as
__float128). But trying to mangle __float128 and long double
differently when they are the same thing is much bigger pain, for libraries
that want to support all that would mean having to export not 5 sets of
floating point entrypoints, but 6 (float, double, long double same as
double, long double same as __ibm128, long double same as __float128,
__float128).

	Jakub

Re: Changes to allow PowerPC to change the long double type to use the IEEE 128-bit floating point format

[Thomas König]

Hi Michael,

I have shortened the distribution list somewhat for the Fortran-relevant
parts.

> I want to discuss changes that I think we need to make across the open source
> toochain to allow us to change the long double type on PowerPC hardware from
> using the IBM extended double (i.e. a pair of doubles) to the IEEE 128-bit
> format defined in IEEE 754.
> 
> I wasn't sure whom to address this to, so I took a scatter shot approach.  I
> likely missed a few people, and some people were added that may not need to
> participate in the discussion.  Sorry for either not including you initially or
> for including you by mistake.
> 
> I added people from the following areas:
> 
> 	PowerPC folk
> 
> 	Langugage maintainers: At the moment, only the C/C++ front ends have
> 	code to support both 128-bit floating point types.  The other languages
> 	use just the defaults provided by the machine maintainers.  However, it
> 	may be we will need to think about rules for code being compiled and
> 	linked with a different long double format.

Currently, we support the IBM format with gfortran.  So, we have to
look at a) library code called from user routines, and b) user code
compiled with one version calling another.

As for a), this is something that can be done using the right m4
macros. We might even, with some hackery, be able to provide two
versions of the functions with the new library.

For b), I do not have a clear solution for Fortran. But I also have
no idea how this is supposed to work in other languages,
when a user uses code compiles something with "long double"
with gcc 10 and links it against "long double" with gcc 11 -
what are your plans for that?

It would be possible to annotate every function with calls long double
with the new format somehow (ugh), or you could make a clear ABI break.
This would mean a new, incompatible version of libgfortran, but we would
have to restrict that to POWER (would that be possible?).
We cannot impose an ABI change on everybody else to this.

Best regards

	Thomas

Re: Changes to allow PowerPC to change the long double type to use the IEEE 128-bit floating point format

[Thomas König]

Just another thought.

In Fortran, we have the possibility to define KIND numbers for
numeric types however we want.

So, it would be no problem to have two long double types
with distinct kind numbers, let's say KIND=16 for
one type and KIND=17 for the other. We can then let
selected_real_kind return the KIND that people should use
(in this case, the IEEE 128-bit format).

We could, for example, leave the IBM long double as KIND=16 and
the IEEE double as a new kind, e.g. 17.  This would have one
advantage: Programs which used KIND=16 would be object-compatible.
There would be two drawbacks: People who use KIND=16 (or REAL*16)
as a shortcut for quadruple precision would not get the speed and
accuracy of the IEEE floats. Plus, KIND=16 would mean something
different on POWER to the rest of the world, where it is IEEE
float (via libquadmath).

If you plan on making this a real ABI change, we could also
choose KIND=16 for the IEEE float, and something else (KIND=15?)
for the IBM float for those people who need it for some
reason or other.

Best regards

	Thomas

Re: Changes to allow PowerPC to change the long double type to use the IEEE 128-bit floating point format

[Michael Meissner]

On Sat, Aug 08, 2020 at 03:33:51PM +0200, Thomas König wrote:
> Hi Michael,
> 
> I have shortened the distribution list somewhat for the Fortran-relevant
> parts.
> 
> >I want to discuss changes that I think we need to make across the open source
> >toochain to allow us to change the long double type on PowerPC hardware from
> >using the IBM extended double (i.e. a pair of doubles) to the IEEE 128-bit
> >format defined in IEEE 754.
> >
> >I wasn't sure whom to address this to, so I took a scatter shot approach.  I
> >likely missed a few people, and some people were added that may not need to
> >participate in the discussion.  Sorry for either not including you initially or
> >for including you by mistake.
> >
> >I added people from the following areas:
> >
> >	PowerPC folk
> >
> >	Langugage maintainers: At the moment, only the C/C++ front ends have
> >	code to support both 128-bit floating point types.  The other languages
> >	use just the defaults provided by the machine maintainers.  However, it
> >	may be we will need to think about rules for code being compiled and
> >	linked with a different long double format.
> 
> Currently, we support the IBM format with gfortran.  So, we have to
> look at a) library code called from user routines, and b) user code
> compiled with one version calling another.

I have patches I'm working through that allows the whole toolchain to be built
with the new default, and I have run through the C, C++, and Fortran test
suites with a new version of glibc.  In fact there were 2-3 tests that
traditionally fail with IBM extended double that now pass.

IMHO, changing the default is only appropriate for times like a distribution
major number changes, where backwards and forwards compatibility is carefully
controlled.  But before we can contemplate doing this, we need the ability to
change the default and have it all work together.

In this case, there were no modifications to the gfortran sources.  It is all
controlled from the rs6000 backend gcc and libgcc machine specific functions.
But there is no backwards compatibility if the user used explicit long double
(in C/C++) or real*16 (gfortran).

One of the keys is changing the names of the built-in functions.  Glibc in
math.h changes all of the long double functions it declares to be either the
IBM extended double or IEEE 128-bit versions of the functions.  Similarly
Libstdc++ is in the middle of doing the changes for tht as well.

In addition, the GNU compiler will change the external names of the built-in
functions to be the IEEE 128-bit names.  This allows for C/C++ users to not use
math.h and still get the right function called (there were a few tests in the
test suite that had to be fixed).  It also allows Gfortran to use these
functions by default.

> 
> As for a), this is something that can be done using the right m4
> macros. We might even, with some hackery, be able to provide two
> versions of the functions with the new library.

Glibc and Libstdc++ are doing this right now.  Tulio, Carlos can speak of
glibc, and Johnathon can speak of libstdc++'s efforts.  Generally in a mixed
library approach, you provide both names, and you do not use long double,
instead you use the explicit types (__ibm128 and __float128) for the two
formats.  Typically they use the -mno-gnu-attributes option which says to
disable the gnu attributes that we use to mark which type of long double is
used, so that it can be linked with either ABI.

 
> For b), I do not have a clear solution for Fortran. But I also have
> no idea how this is supposed to work in other languages,
> when a user uses code compiles something with "long double"
> with gcc 10 and links it against "long double" with gcc 11 -
> what are your plans for that?
> 
> It would be possible to annotate every function with calls long double
> with the new format somehow (ugh), or you could make a clear ABI break.
> This would mean a new, incompatible version of libgfortran, but we would
> have to restrict that to POWER (would that be possible?).
> We cannot impose an ABI change on everybody else to this.

We do annotate each function that has long double arguments or returns long
double arguments already with gnu attributes.  There are some issues with it,
and I want to delve into it deeper.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797

Re: Changes to allow PowerPC to change the long double type to use the IEEE 128-bit floating point format

[Thomas König]

Am 10.08.20 um 18:53 schrieb Michael Meissner:
> IMHO, changing the default is only appropriate for times like a distribution
> major number changes, where backwards and forwards compatibility is carefully
> controlled.  But before we can contemplate doing this, we need the ability to
> change the default and have it all work together.

That is, of course, true.

However, we should already think ahead.  If this change is done the
way you describe, where we would just change REAL(KIND=16) from
__ibm128 to __float128, this is a binary incompatible change,
and libgfortran needs a new major revision number on POWER. I see
no way around that.

Best regards

	Thomas

Re: Changes to allow PowerPC to change the long double type to use the IEEE 128-bit floating point format

[H.J. Lu]

On Fri, Aug 7, 2020 at 1:57 PM Michael Meissner via Gcc <gcc@gcc.gnu.org> wrote:
>
> I want to discuss changes that I think we need to make across the open source
> toochain to allow us to change the long double type on PowerPC hardware from
> using the IBM extended double (i.e. a pair of doubles) to the IEEE 128-bit
> format defined in IEEE 754.
>
> I wasn't sure whom to address this to, so I took a scatter shot approach.  I
> likely missed a few people, and some people were added that may not need to
> participate in the discussion.  Sorry for either not including you initially or
> for including you by mistake.
>
> I added people from the following areas:
>
>         PowerPC folk
>
>         Langugage maintainers: At the moment, only the C/C++ front ends have
>         code to support both 128-bit floating point types.  The other languages
>         use just the defaults provided by the machine maintainers.  However, it
>         may be we will need to think about rules for code being compiled and
>         linked with a different long double format.
>
>         Arm/x86 maintainers: It is possible that these sorts of changes might
>         mesh with things that are being planned.  For example, maybe x86 might
>         want to explore changing the default for long double from the
>         traditional Intel 80-bit format to IEEE 128-bit.  And there might be
>         issues with the several different 16-bit floating point formats
>         floating around.

Do you need to check mixed formats in different relocatable/shared
object files at link-time and in different shared objects/executable at
run-time?

H.J.

First set of patches to allow changing the long double default were posted:

[Michael Meissner]

I posted version 1 of the patches of the stuff needed to allow little endian
64-bit GCC on Linux to be configured to use long double.

As per the discussion in this thread, I did decide to keep things to two types
within the compiler.  This means that an explicit __float128 or _Float128 will
use the same type node and TFmode as long double uses if the default for long
double is IEEE 128-bit.

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554765.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797

Re: First set of patches to allow changing the long double default were posted:

[Joseph Myers]

On Thu, 24 Sep 2020, Michael Meissner wrote:

> As per the discussion in this thread, I did decide to keep things to two types
> within the compiler.  This means that an explicit __float128 or _Float128 will
> use the same type node and TFmode as long double uses if the default for long
> double is IEEE 128-bit.

I'm not sure which patch in the series is supposed to be implementing 
that, but C requires that long double and _Float128 are distinct types (so 
you can use _Generic to choose between them, for example) even if they 
have the same ABI.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: First set of patches to allow changing the long double default were posted:

[Michael Meissner]

On Mon, Sep 28, 2020 at 04:38:51PM +0000, Joseph Myers wrote:
> On Thu, 24 Sep 2020, Michael Meissner wrote:
> 
> > As per the discussion in this thread, I did decide to keep things to two types
> > within the compiler.  This means that an explicit __float128 or _Float128 will
> > use the same type node and TFmode as long double uses if the default for long
> > double is IEEE 128-bit.
> 
> I'm not sure which patch in the series is supposed to be implementing 
> that, but C requires that long double and _Float128 are distinct types (so 
> you can use _Generic to choose between them, for example) even if they 
> have the same ABI.

Hmmm, but others said that it would complicate things if __float128 were
different than long double.  I've implemented it both ways (I would have to dig
up the patches to have separate types).

And doing so might break all of the glibc efforts to provide dual symbols.

I could obviously use __float128 to be the same as long double, and _Float128
being a unique type if long double is IEEE.  And since C++ doesn't have
_Float128, it would 'work' without introducing a new mangling name.

I don't think there is a solution that doesn't break something.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797

Re: First set of patches to allow changing the long double default were posted:

[Jakub Jelinek]

On Mon, Sep 28, 2020 at 05:07:55PM -0400, Michael Meissner wrote:
> On Mon, Sep 28, 2020 at 04:38:51PM +0000, Joseph Myers wrote:
> > On Thu, 24 Sep 2020, Michael Meissner wrote:
> > 
> > > As per the discussion in this thread, I did decide to keep things to two types
> > > within the compiler.  This means that an explicit __float128 or _Float128 will
> > > use the same type node and TFmode as long double uses if the default for long
> > > double is IEEE 128-bit.
> > 
> > I'm not sure which patch in the series is supposed to be implementing 
> > that, but C requires that long double and _Float128 are distinct types (so 
> > you can use _Generic to choose between them, for example) even if they 
> > have the same ABI.
> 
> Hmmm, but others said that it would complicate things if __float128 were
> different than long double.  I've implemented it both ways (I would have to dig
> up the patches to have separate types).
> 
> And doing so might break all of the glibc efforts to provide dual symbols.
> 
> I could obviously use __float128 to be the same as long double, and _Float128
> being a unique type if long double is IEEE.  And since C++ doesn't have
> _Float128, it would 'work' without introducing a new mangling name.

That seems preferrable to me.

	Jakub

Re: First set of patches to allow changing the long double default were posted:

[Joseph Myers]

On Mon, 28 Sep 2020, Michael Meissner via Gcc wrote:

> > I'm not sure which patch in the series is supposed to be implementing 
> > that, but C requires that long double and _Float128 are distinct types (so 
> > you can use _Generic to choose between them, for example) even if they 
> > have the same ABI.
> 
> Hmmm, but others said that it would complicate things if __float128 were
> different than long double.  I've implemented it both ways (I would have to dig
> up the patches to have separate types).
> 
> And doing so might break all of the glibc efforts to provide dual symbols.
> 
> I could obviously use __float128 to be the same as long double, and _Float128
> being a unique type if long double is IEEE.  And since C++ doesn't have
> _Float128, it would 'work' without introducing a new mangling name.

My comment is specifically about _Float128, in C; it doesn't say anything 
about what should happen for C++ (though it would be nice to resolve the 
ICEs that occur when _FloatN / _FloatNx types leak into C++ code via 
built-in functions, bug 85518).  Maybe it makes sense for the type (or at 
least the type used by the built-in functions and __float128, since 
_Float128 itself can't be accessed directly in C++) to be the same in the 
C++ case.

The existing code in build_common_tree_nodes that creates all the _FloatN 
/ _FloatNx type nodes always creates a new node with make_node.  And since 
I didn't spot anything in your patch series that changes that, I couldn't 
see how that patch series actually does make them the same type.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: First set of patches to allow changing the long double default were posted:

[Jonathan Wakely]

On Mon, 28 Sep 2020 at 23:15, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Mon, 28 Sep 2020, Michael Meissner via Gcc wrote:
>
> > > I'm not sure which patch in the series is supposed to be implementing
> > > that, but C requires that long double and _Float128 are distinct types (so
> > > you can use _Generic to choose between them, for example) even if they
> > > have the same ABI.
> >
> > Hmmm, but others said that it would complicate things if __float128 were
> > different than long double.  I've implemented it both ways (I would have to dig
> > up the patches to have separate types).
> >
> > And doing so might break all of the glibc efforts to provide dual symbols.
> >
> > I could obviously use __float128 to be the same as long double, and _Float128
> > being a unique type if long double is IEEE.  And since C++ doesn't have
> > _Float128, it would 'work' without introducing a new mangling name.
>
> My comment is specifically about _Float128, in C; it doesn't say anything
> about what should happen for C++ (though it would be nice to resolve the
> ICEs that occur when _FloatN / _FloatNx types leak into C++ code via
> built-in functions, bug 85518).  Maybe it makes sense for the type (or at
> least the type used by the built-in functions and __float128, since
> _Float128 itself can't be accessed directly in C++) to be the same in the
> C++ case.

I imagine C++  will want to support _Float128 at some point, with
similar semantics to C.

But if __float128 is the same type as __ieee128 (which is sometimes
the same as long double), which is a different type to _Float128, then
I think that will work for both C and C++.

If the standards say we have a standard _Float128 type which is
different to long double, that's fine. If the standard wants a
different type, we'll support that. What I'd like to avoid is a
non-standard __float128 type that is a different type to long double
even if they use the same representation. That seems like a needless
difference just for the sake of it.

Re: First set of patches to allow changing the long double default were posted:

[Joseph Myers]

On Tue, 29 Sep 2020, Jonathan Wakely via Gcc wrote:

> I imagine C++  will want to support _Float128 at some point, with
> similar semantics to C.

Unless it chooses a class-based approach like that used for 
std::decimal::decimal128.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: First set of patches to allow changing the long double default were posted:

[Michael Meissner]

On Tue, Sep 29, 2020 at 05:34:55PM +0100, Jonathan Wakely wrote:
> On Mon, 28 Sep 2020 at 23:15, Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Mon, 28 Sep 2020, Michael Meissner via Gcc wrote:
> >
> > > > I'm not sure which patch in the series is supposed to be implementing
> > > > that, but C requires that long double and _Float128 are distinct types (so
> > > > you can use _Generic to choose between them, for example) even if they
> > > > have the same ABI.
> > >
> > > Hmmm, but others said that it would complicate things if __float128 were
> > > different than long double.  I've implemented it both ways (I would have to dig
> > > up the patches to have separate types).
> > >
> > > And doing so might break all of the glibc efforts to provide dual symbols.
> > >
> > > I could obviously use __float128 to be the same as long double, and _Float128
> > > being a unique type if long double is IEEE.  And since C++ doesn't have
> > > _Float128, it would 'work' without introducing a new mangling name.
> >
> > My comment is specifically about _Float128, in C; it doesn't say anything
> > about what should happen for C++ (though it would be nice to resolve the
> > ICEs that occur when _FloatN / _FloatNx types leak into C++ code via
> > built-in functions, bug 85518).  Maybe it makes sense for the type (or at
> > least the type used by the built-in functions and __float128, since
> > _Float128 itself can't be accessed directly in C++) to be the same in the
> > C++ case.
> 
> I imagine C++  will want to support _Float128 at some point, with
> similar semantics to C.
> 
> But if __float128 is the same type as __ieee128 (which is sometimes
> the same as long double), which is a different type to _Float128, then
> I think that will work for both C and C++.
> 
> If the standards say we have a standard _Float128 type which is
> different to long double, that's fine. If the standard wants a
> different type, we'll support that. What I'd like to avoid is a
> non-standard __float128 type that is a different type to long double
> even if they use the same representation. That seems like a needless
> difference just for the sake of it.

As Segher says, I sometimes confuse 'types' with 'modes'.

I looked into this a bit, and I think we want to keep the current behavior (as
modified by the patches).  As Joseph says, the _Float<n> types have their own
types, but may/may not use the same modes as other types.  Obviously if these
types leak into C++ (i.e. but 85518), then something needs to be done about
mangling.  But that is a machine independent issue, not a PowerPC issue.

Note, when I began the thread, I had talked about separating the types so that
internally we have 3 types (__float128, __ibm128, and long double), and in fact
I had made changes to that effect in a local sandbox.  The discussion convinced
me that we probably don't want to go down this path.

I did play around with making _Float128 always use KFmode, but it will cause us
to need other changes.  I can do these changes if needed, but it seems like a
lot of pointless work.

To summarize, the current state is:

1) If long double is IEEE 128-bit floating point.

	_Float128 has its own type, and uses TFmode;

	__float128/__ieee128 uses the long double type and uses TFmode;

	__ibm128 uses its own type, and uses IFmode.

	Mangling:
		__float128	=> "u9__ieee128"
		__ibm128	=> "g"
		long double	=> "u9__ieee128"

2) If long double is IBM extended double:

	_Float128 has its own type, and uses KFmode;

	__float128/__ieee128 uses its own type, and uses KFmode.

	__ibm128 uses the long double type and uses TFmode.

	Mangling:
		__float128	=> "u9__ieee128"
		__ibm128	=> "g"
		long double	=> "g"

3) If long double is 64-bits:

	_Float128 has its own type, and uses KFmode;

	__float128/__ieee128 uses its own type, and uses KFmode.

	__ibm128 uses its own type and uses IFmode.

	Mangling:
		__float128	=> "u9__ieee128"
		__ibm128	=> "g"
		long double	=> "e"

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797

Re: First set of patches to allow changing the long double default were posted:

[Segher Boessenkool]

Hi!

On Wed, Oct 07, 2020 at 08:00:49PM -0400, Michael Meissner wrote:
> I looked into this a bit, and I think we want to keep the current behavior (as
> modified by the patches).  As Joseph says, the _Float<n> types have their own
> types, but may/may not use the same modes as other types.  Obviously if these
> types leak into C++ (i.e. but 85518), then something needs to be done about
> mangling.  But that is a machine independent issue, not a PowerPC issue.

There is DF128_ defined for just this, fwiw.  (See
<https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin>.)

> I did play around with making _Float128 always use KFmode, but it will cause us
> to need other changes.  I can do these changes if needed, but it seems like a
> lot of pointless work.

It would be ideal if we would never have TFmode stuff in the instruction
stream, only IFmode and KFmode.  Hey, I can dream :-)


Segher