* Potential upcoming changes in mangling to PowerPC GCC @ 2022-08-03 22:21 Michael Meissner [not found] ` <CAAJqyv4_RQ=di2WcDN+n0j4rWQQNtcnaT_6MkyFHie9oDQY1bg@mail.gmail.com> 0 siblings, 1 reply; 4+ messages in thread From: Michael Meissner @ 2022-08-03 22:21 UTC (permalink / raw) To: GCC Development, Michael Meissner, Segher Boessenkool, Kewen.Lin, David Edelsohn, Peter Bergner, Will Schmidt, Jason Merrill, Nathan Sidwell, Mike Stump, Iain Sandoe, Joseph Myers, Tulio Magno Quites Machado Filho, Alan Modra, Nick Clifton, Jeff Law, Jakub Jelinek, Richard Biener, David S. Miller, Carlos O'Donell Cc: libc-maintainers mailing list Note, I tried to send this out before, but it didn't seem to go out. Sorry if you got it twice. Sorry for the scatter shot mail that covers C++, Objective C++, Glibc, etc. developers, but I wanted to discuss and get buy-in on changes to the PowerPC GCC compiler that I would like to do in the endless project of supporting IEEE 128-bit floating point. Sorry if I spammed your inbox if this doesn't concern you. At the moment, GCC 12 on the server PowerPC systems supports multiple 128-bit floating point types: * _Float128 (in the C language): IEEE 128-bit floating point; * __float128 (in the C and C++ languages): IEEE 128-bit floating point; * long double: One of IEEE 128-bit floating, IBM 128-bit floating point, or 64-bit floating point; (and) * __ibm128: Explicit IBM 128-bit floating point. And there are 3 modes: * KFmode: IEEE 128-bit floating point; * IFmode: IBM 128-bit floating point; (and) * TFmode: Either IEEE 128-bit or IBM 128-bit floating point. But internally within the compiler there are mostly only two separate types, an IEEE 128-bit and IBM 128-bit floating point. If a file is compiled when long double uses the IEEE 128-bit floating point type, then the __float128 type is the long double type and it uses the TFmode mode. And while the _Float128 type is distinct from long double, it also uses TFmode. The __ibm128 type is distinct, and it uses IFmode. If a file is compiled when long double uses IBM 128-bit floating point, then the __float128 type uses the _Float128 type, and both types use KFmode. The __ibm128 type uses the long double type, and both types use TFmode. While things mostly work with this setup, there are some things that don't work as well. For example, 3 of the tests fail when you are using a system like Fedora 36 where IEEE 128-bit long double is default. These 3 tests use the 'nanqs' built-in function, which is mapped to 'nanf128s' and it delivers a _Float128 signaling NaN. But since __float128 uses a different type, the signaling NaN is converted and it loses the signaling property. The tests that fail are: * gcc.dg/torture/float128-nan.c * gcc.target/powerpc/nan128-1.c * gcc.target/powerpc/pr105334.c In addition, it would be nice if we could refine the setting of bits in the ELF header so that if you pass an explicit __float128 or __ibm128 object, it doesn't set the bits that you used long double of the appropriate type. But the code that sets these bits is done in the RTL stages, and it only looks at modes, not at types. Now, I'm working on patches to 'do the right thing': * Make _Float128 and __float128 always use the same distinct type and always use KFmode; * Make __ibm128 use a distinct type and always use IFmode; (and) * Long double would not share an internal type with either _Float128, __float128, or __ibm128. It would always use TFmode. One of the issues that comes up is the mangling support. I wanted to get buy-in on the solutions from the affected users: Because long double mangles the same as either __float128 or __ibm128, you cannot write programs like: double convert (__ibm128 x) { return x; } double convert (__float128 x) { return x; } double convert (long double x) { return x; } You would have to write on a system with long double being IBM 128-bit: double convert (__float128 x) { return x; } double convert (long double x) { return x; } or on a system with long double being IEEE 128-bit: double convert (__ibm128 x) { return x; } double convert (long double x) { return x; } At the moment, the mangling rules are: * If the type uses the IBM 128-bit encoding, use "g" for mangling; * If the type uses the IEEE 128-bit encoding, use "u9__ieee128" for mangling. I would suggest at least adding the rule: * If the type is explicitly __ibm128, use "u8__ibm128" for the mangling, and if it is long double that uses the IBM 128-bit encoding, continue to use "g" for the mangling. This shows up in the test suite g++.target/powerpc/pr85657.C. We probably should think about the reverse case of separating explict __float128 from long double that happens to use the IEEE 128-bit encoding. I suspect the right solution is to change the mangling on __float128 and leave long double alone. If so, any ideas on the mangling we should use? Perhaps we should use "DF128" which is the mangling for ISO/IEC TS 18661 _Float<N> type. But in changing the mangling, we have the potential to create compatibility issues, of code compiled with previous GCC's that use explicit __ibm128 and __float128 keywords. I don't how the users of these keywords (i.e. typically libstdc++ and glibc developers, but potentially others as well). -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <CAAJqyv4_RQ=di2WcDN+n0j4rWQQNtcnaT_6MkyFHie9oDQY1bg@mail.gmail.com>]
* Re: Potential upcoming changes in mangling to PowerPC GCC [not found] ` <CAAJqyv4_RQ=di2WcDN+n0j4rWQQNtcnaT_6MkyFHie9oDQY1bg@mail.gmail.com> @ 2022-08-04 17:58 ` Michael Meissner 2022-08-04 21:14 ` Jonathan Wakely 0 siblings, 1 reply; 4+ messages in thread From: Michael Meissner @ 2022-08-04 17:58 UTC (permalink / raw) To: Nathan Sidwell Cc: Michael Meissner, GCC Development, Segher Boessenkool, Kewen.Lin, David Edelsohn, Peter Bergner, Will Schmidt, Jason Merrill, Mike Stump, Iain Sandoe, Joseph Myers, Tulio Magno Quites Machado Filho, Alan Modra, Nick Clifton, Jeff Law, Jakub Jelinek, Richard Biener, David S. Miller, Carlos O'Donell, libc-alpha On Thu, Aug 04, 2022 at 10:49:24AM +0200, Nathan Sidwell wrote: > Not a problem. I don't think I have anything to add- I presume you've > thought about (weak) aliases to deal with the problematic changes you > mention towards the end? I've thought about it. I know in the past we had weak aliases to do the support the same way when we had the last name mangling change. I know those aliases weren't popular back then. Part of the reason for asking is I don't have a sense for how library maintainers use the __float128 and __ibm128 keywords. Do they treat them as full fledged types, or are they just convenient ways to compile code with both names rather than building two modules, with the different long double types? -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Potential upcoming changes in mangling to PowerPC GCC 2022-08-04 17:58 ` Michael Meissner @ 2022-08-04 21:14 ` Jonathan Wakely 2022-08-08 21:35 ` Michael Meissner 0 siblings, 1 reply; 4+ messages in thread From: Jonathan Wakely @ 2022-08-04 21:14 UTC (permalink / raw) To: Michael Meissner, Nathan Sidwell, GCC Development, Segher Boessenkool, Kewen.Lin, David Edelsohn, Peter Bergner, Will Schmidt, Jason Merrill, Mike Stump, Iain Sandoe, Joseph Myers, Tulio Magno Quites Machado Filho, Alan Modra, Nick Clifton, Jeff Law, Jakub Jelinek, Richard Biener, David S. Miller, Carlos O'Donell, GNU C Library On Thu, 4 Aug 2022 at 18:58, Michael Meissner via Gcc <gcc@gcc.gnu.org> wrote: > > On Thu, Aug 04, 2022 at 10:49:24AM +0200, Nathan Sidwell wrote: > > Not a problem. I don't think I have anything to add- I presume you've > > thought about (weak) aliases to deal with the problematic changes you > > mention towards the end? > > I've thought about it. I know in the past we had weak aliases to do the > support the same way when we had the last name mangling change. I know those > aliases weren't popular back then. > > Part of the reason for asking is I don't have a sense for how library > maintainers use the __float128 and __ibm128 keywords. Do they treat them as > full fledged types, or are they just convenient ways to compile code with both > names rather than building two modules, with the different long double types? Within libstdc++ it's not just a minor convenience, it's 100% necessary to refer to both kinds (IEEE 128 and IBM 128) in the same translation unit. There are C++ classes with member functions taking both types, e.g. struct Foo { void f(__ibm128); void f(__ieee128); }; You can't do this by "building two modules" because it's a header and you can't split the definition of a class across two different files. And in many cases, it's a class template, so you can't even hide the definition of the function in a .cc file, it has to be defined in the header. So libstdc++ 100% requires a way to refer to "the type that is long double" (which is easy, that's 'long double') and "the other 128-bit type that isn't long double" (which is one of __ibm128 or __ieee128). So we need to refer to *at least* one of __ibm128 or __ieee128, and in some cases it's simpler to not refer to 'long double' at all (because its meaning can change) and just refer to __ibm128 and __ieee128 because those always mean the same thing. If the names or mangling for either of those types changes, it would break libstdc++ and require more work just to restore the existing functionality. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Potential upcoming changes in mangling to PowerPC GCC 2022-08-04 21:14 ` Jonathan Wakely @ 2022-08-08 21:35 ` Michael Meissner 0 siblings, 0 replies; 4+ messages in thread From: Michael Meissner @ 2022-08-08 21:35 UTC (permalink / raw) To: Jonathan Wakely Cc: Michael Meissner, Nathan Sidwell, GCC Development, Segher Boessenkool, Kewen.Lin, David Edelsohn, Peter Bergner, Will Schmidt, Jason Merrill, Mike Stump, Iain Sandoe, Joseph Myers, Tulio Magno Quites Machado Filho, Alan Modra, Nick Clifton, Jeff Law, Jakub Jelinek, Richard Biener, David S. Miller, Carlos O'Donell, GNU C Library On Thu, Aug 04, 2022 at 10:14:10PM +0100, Jonathan Wakely wrote: > On Thu, 4 Aug 2022 at 18:58, Michael Meissner via Gcc <gcc@gcc.gnu.org> wrote: > > > > On Thu, Aug 04, 2022 at 10:49:24AM +0200, Nathan Sidwell wrote: > > > Not a problem. I don't think I have anything to add- I presume you've > > > thought about (weak) aliases to deal with the problematic changes you > > > mention towards the end? > > > > I've thought about it. I know in the past we had weak aliases to do the > > support the same way when we had the last name mangling change. I know those > > aliases weren't popular back then. > > > > Part of the reason for asking is I don't have a sense for how library > > maintainers use the __float128 and __ibm128 keywords. Do they treat them as > > full fledged types, or are they just convenient ways to compile code with both > > names rather than building two modules, with the different long double types? > > > Within libstdc++ it's not just a minor convenience, it's 100% > necessary to refer to both kinds (IEEE 128 and IBM 128) in the same > translation unit. There are C++ classes with member functions taking > both types, e.g. > > struct Foo { > void f(__ibm128); > void f(__ieee128); > }; > > You can't do this by "building two modules" because it's a header and > you can't split the definition of a class across two different files. > And in many cases, it's a class template, so you can't even hide the > definition of the function in a .cc file, it has to be defined in the > header. So libstdc++ 100% requires a way to refer to "the type that is > long double" (which is easy, that's 'long double') and "the other > 128-bit type that isn't long double" (which is one of __ibm128 or > __ieee128). So we need to refer to *at least* one of __ibm128 or > __ieee128, and in some cases it's simpler to not refer to 'long > double' at all (because its meaning can change) and just refer to > __ibm128 and __ieee128 because those always mean the same thing. > > If the names or mangling for either of those types changes, it would > break libstdc++ and require more work just to restore the existing > functionality. I tend to agree that only having mangling for two 128-bit types (ieee and ibm), no matter what they are called is better than trying to support 3 separate types (explict ieee, explicit ibm, and whatever long double is). That way we don't have to come up with new mangling forms, which has backwards compatibility issues. But it is possible as distros move from having the default long double being IBM to being IEEE, we will see disconnect in user code, where they want to use long double and add an explicit __float128 type. I imagine if x86 ever flips the switch so that -mlong-double-128 is default (instead of -mlong-double-80), they would see the same issues between using __float128 and long double. And libstdc++ and glibc not using explicit long double is likely the best way to avoid all of the issues. There are still likely issues in moving from the current implementation, but it is simpler if we don't have to have 4 different mangling forms (the explicit forms, and the 2 forms for long double). -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-08-08 21:35 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-08-03 22:21 Potential upcoming changes in mangling to PowerPC GCC Michael Meissner [not found] ` <CAAJqyv4_RQ=di2WcDN+n0j4rWQQNtcnaT_6MkyFHie9oDQY1bg@mail.gmail.com> 2022-08-04 17:58 ` Michael Meissner 2022-08-04 21:14 ` Jonathan Wakely 2022-08-08 21:35 ` Michael Meissner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).