Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On 05.10.21 23:54, Segher Boessenkool wrote: Hi! On Tue, Oct 05, 2021 at 10:16:47PM +0200, Thomas Koenig wrote: On 04.10.21 16:14, Jakub Jelinek via Fortran wrote: Based on some IRC discussion, yet another option would be bump libgfortran SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean always IEEE quad (starting with GCC 12) and if wanted add support for real(kind=15) meaning double double. Bumping the SONAME for everybody even on architectures which are not affected (like x86 or ARM) does not really feel right. We will probably have to do it sooner or later, at least to get PDTs right (and for array descriptor reform), but we will then have to do another SONAME change when we do that (it is certainly not ready now). You do not have to change soname more than once per release. You could leave it at the old value for archs not affected. It is good for everyone's sanity to keep the same numbers for all archs though, so, just skip some for some archs. That's the best way, I think - no disruption on all other systems. Everyone who uses -static won't be hurt either way. There is also the issue of binary data. If some user has written out data in double double and wants to read it in as IEEE quad, the results are going to be garbage. Another option for CONVERT might be the solution to that, or, as you wrote, having a REAL(KIND=15). It should be inaccessible via SELECTED_REAL_KIND, though. That means flipping the default on all PowerPC to no longer be double- double. This means that you should have IEEE QP work everywhere, or the people who do need more than double precision will have no recourse. I think we can exclude big-endian POWER from this - they do not have IEEE QP support, correct? So, exclude that from the SONAME change. So this would only be critical for people on little-endian POWER8 who use double double. Hmm... can the POWER8 handle the IEEE QP instructions, or would that be trap and emulate? What is the plan there? It will be great if you can do this at the same time, get all the pain over with at the same time, have better results for everyone. Heck, you only need the "kind=15" for compatibility then. It would still mean that people would have to change their source code, especially those who have followed the standard convention of using selected_real_kind. Not sure what the consequences would be. People who have data stored in the old format will be in a tough spot no matter what. Presumably everyone will want to convert to the standard format at some point. In that case, extending the CONVERT option to the OPEN statement might be the best way (plus the corresponding handling of the environment variables and options). It would be slow, especially when honoring NaN and INF, but people could at least read in data and then write it out again. Best regards Thomas
Including documentation files with gcc releases
Have been scrutinising the GCC 11.2 Download. I would appreciate if you start including the gcc source files for the documentation in the release as well.
Đèffef
Có Uh R rr r rv Được gửi r cg vwtừ iPhone của tôi để ge rrb
Re: Including documentation files with gcc releases
On Wed, 6 Oct 2021 at 13:07, dimechc via Gcc wrote: > > Have been scrutinising the GCC 11.2 Download. I would appreciate if you start > including the gcc source files for the documentation > in the release as well. They should be present already. Which documentation are you talking about?
Including documentation files with gcc releases
I got the GCC 11.2 download, but cannot locate the doc directory used to produce the gcc documentation manuals. ‐‐‐ Original Message ‐‐‐ On Wednesday, October 6th, 2021 at 12:32 PM, Jonathan Wakely wrote: > On Wed, 6 Oct 2021 at 13:07, dimechc via Gcc gcc@gcc.gnu.org wrote: > > > Have been scrutinising the GCC 11.2 Download. I would appreciate if you > > start including the gcc source files for the documentation > > > > in the release as well. > > They should be present already. Which documentation are you talking about?
Re: Including documentation files with gcc releases
On Wed, Oct 06, 2021 at 01:19:28PM +, dimechc via Gcc wrote: > I got the GCC 11.2 download, but cannot locate the doc directory used to > produce the > gcc documentation manuals. gcc/doc/, gcc/*/*.texi, libstdc++-v3/doc/, lib*/*.texi, ... Jakub
Re: Including documentation files with gcc releases
On Wed, 6 Oct 2021, 14:19 dimechc, wrote: > I got the GCC 11.2 download, but cannot locate the doc directory used to > produce the > gcc documentation manuals. > You still haven't said which documentation you're talking about. GCC has lots of documentation. All the sources should be in the release tarball but if you can't tell us which docs you're talking about, we can't point to the specific sources for those docs. It seems you haven't really looked very hard though. You should have grep and find utilities that can help. > > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, October 6th, 2021 at 12:32 PM, Jonathan Wakely < > jwakely@gmail.com> wrote: > > > On Wed, 6 Oct 2021 at 13:07, dimechc via Gcc gcc@gcc.gnu.org wrote: > > > > > Have been scrutinising the GCC 11.2 Download. I would appreciate if > you start including the gcc source files for the documentation > > > > > > in the release as well. > > > > They should be present already. Which documentation are you talking > about? >
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote: > On 05.10.21 23:54, Segher Boessenkool wrote: > >>There is also the issue of binary data. If some user has written > >>out data in double double and wants to read it in as IEEE quad, > >>the results are going to be garbage. Another option for CONVERT > >>might be the solution to that, or, as you wrote, having a > >>REAL(KIND=15). It should be inaccessible via SELECTED_REAL_KIND, > >>though. > > > >That means flipping the default on all PowerPC to no longer be double- > >double. This means that you should have IEEE QP work everywhere, or the > >people who do need more than double precision will have no recourse. > > I think we can exclude big-endian POWER from this - they do not have > IEEE QP support, correct? So, exclude that from the SONAME change. Not correct, no. IEEE QP works fine in either endianness. I don't know what the libraries do, but in GCC it works just fine. > So this would only be critical for people on little-endian POWER8 > who use double double. Hmm... can the POWER8 handle the IEEE QP > instructions, or would that be trap and emulate? What is the > plan there? The registers used by the QP insns are the VRs. Trying to use the QP insns on a p8 will trap. There is no kernel emulation for them afaik. But, for p8 there is software emulation, that GCC can generate. This follows the ABI as for p9 and later. > >It will be great if you can do this at the same time, get all the pain > >over with at the same time, have better results for everyone. Heck, you > >only need the "kind=15" for compatibility then. > > It would still mean that people would have to change their source code, > especially those who have followed the standard convention of > using selected_real_kind. Not sure what the consequences would be. Yes, that is pain. But pain once :-) > >People who have data stored in the old format will be in a tough spot > >no matter what. Presumably everyone will want to convert to the > >standard format at some point. > > In that case, extending the CONVERT option to the OPEN statement > might be the best way (plus the corresponding handling of the > environment variables and options). It would be slow, especially > when honoring NaN and INF, but people could at least read in data and > then write it out again. Converting double-double to IEEE QP should not be hard or slow? Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote: > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote: > > On 05.10.21 23:54, Segher Boessenkool wrote: > > >>There is also the issue of binary data. If some user has written > > >>out data in double double and wants to read it in as IEEE quad, > > >>the results are going to be garbage. Another option for CONVERT > > >>might be the solution to that, or, as you wrote, having a > > >>REAL(KIND=15). It should be inaccessible via SELECTED_REAL_KIND, > > >>though. > > > > > >That means flipping the default on all PowerPC to no longer be double- > > >double. This means that you should have IEEE QP work everywhere, or the > > >people who do need more than double precision will have no recourse. > > > > I think we can exclude big-endian POWER from this - they do not have > > IEEE QP support, correct? So, exclude that from the SONAME change. > > Not correct, no. IEEE QP works fine in either endianness. But only for Power8 or later, no? I guess the reason why le can switch moreless easily (well, far from it, it is terribly hard anyway) is that power8 is the oldest supported ISA for le, while be can't really assume power8 or later. Also, seems e.g. glibc support is there only for ppc64le and not be: find . -name libm.abilist | xargs grep sinieee128 ./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 __asinieee128 F ./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 __casinieee128 F ./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 __csinieee128 F ./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 __sinieee128 F Jakub
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool wrote: > > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote: > > On 05.10.21 23:54, Segher Boessenkool wrote: > > >>There is also the issue of binary data. If some user has written > > >>out data in double double and wants to read it in as IEEE quad, > > >>the results are going to be garbage. Another option for CONVERT > > >>might be the solution to that, or, as you wrote, having a > > >>REAL(KIND=15). It should be inaccessible via SELECTED_REAL_KIND, > > >>though. > > > > > >That means flipping the default on all PowerPC to no longer be double- > > >double. This means that you should have IEEE QP work everywhere, or the > > >people who do need more than double precision will have no recourse. > > > > I think we can exclude big-endian POWER from this - they do not have > > IEEE QP support, correct? So, exclude that from the SONAME change. > > Not correct, no. IEEE QP works fine in either endianness. This needs to be described with more granularity. IEEE QP instructions work with either endianness. IEEE QP is enabled and supported for PPC64 LE Linux on Power. The transition is under discussion. PPC64 BE Linux on Power does not define IEEE QP. The ABI could be updated and IEEE QP could be enabled, but PPC64 BE is not planning future releases from Linux distros. IEEE QP for PPC64 FreeBSD on Power is an open question for the FreeBSD community. AIX on Power will continue to use double-double long double format. GCC, LLVM, IBM Open XL and IBM XL compilers will continue to implement and support the double-double format on AIX. Thanks, David P.S. This is my personal understanding and not an official statement of support or product guidance from IBM.
Including documentation files with gcc releases
‐‐‐ Original Message ‐‐‐ On Wednesday, October 6th, 2021 at 2:50 PM, Jonathan Wakely wrote: > On Wed, 6 Oct 2021, 14:19 dimechc, wrote: > >> I got the GCC 11.2 download, but cannot locate the doc directory used to >> produce the >> gcc documentation manuals. > > You still haven't said which documentation you're talking about. > > GCC has lots of documentation. All the sources should be in the release > tarball but if you can't tell us which docs you're talking about, we can't > point to the specific sources for those docs. > > It seems you haven't really looked very hard though. You should have grep and > find utilities that can help. Jakub directed me to gcc/doc/, gcc/*/*.texi, libstdc++-v3/doc/, lib*/*.texi, ... I am more used to emacs, and the doc directory is easier to locate as it is a top lever directory. The documentation I am referring to is the code provided in https://gcc.gnu.org/onlinedocs/11.2.0/ Do there exist other gcc-related documention files not present in the gcc release? I am looking at gcc-11.2.0.tar.gz (2021-07-28 08:15 137M) ? >> ‐‐‐ Original Message ‐‐‐ >> >> On Wednesday, October 6th, 2021 at 12:32 PM, Jonathan Wakely >> wrote: >> >>> On Wed, 6 Oct 2021 at 13:07, dimechc via Gcc gcc@gcc.gnu.org wrote: >>> >>> > Have been scrutinising the GCC 11.2 Download. I would appreciate if you >>> > start including the gcc source files for the documentation >>> > >>> > in the release as well. >>> >>> They should be present already. Which documentation are you talking about?
Re: Including documentation files with gcc releases
On Wed, Oct 06, 2021 at 03:57:35PM +, dimechc via Gcc wrote: > ‐‐‐ Original Message ‐‐‐ > On Wednesday, October 6th, 2021 at 2:50 PM, Jonathan Wakely > wrote: > > > On Wed, 6 Oct 2021, 14:19 dimechc, wrote: > > > >> I got the GCC 11.2 download, but cannot locate the doc directory used to > >> produce the > >> gcc documentation manuals. > > > > You still haven't said which documentation you're talking about. > > > > GCC has lots of documentation. All the sources should be in the release > > tarball but if you can't tell us which docs you're talking about, we can't > > point to the specific sources for those docs. > > > > It seems you haven't really looked very hard though. You should have grep > > and find utilities that can help. > > Jakub directed me to gcc/doc/, gcc/*/*.texi, libstdc++-v3/doc/, lib*/*.texi, > ... > > I am more used to emacs, and the doc directory is easier to locate as it is a > top lever directory. > > The documentation I am referring to is the code provided in > > https://gcc.gnu.org/onlinedocs/11.2.0/ > > Do there exist other gcc-related documention files not present in the gcc > release? I am looking at gcc-11.2.0.tar.gz (2021-07-28 08:15 137M) ? The *.texi files which are the sources for most of the documentation are there, including on git branches. The *.info files generated from those using the gcc Makefiles are there in release tarballs, but not on git branches, one needs to build gcc and when building it it will be generated. If you mean other formats, that needs other tools to generate them, and some of them can be created with e.g. make pdf in gcc directory or make html etc., or there is the maintainer-scripts/update_web_docs_git script that can generate what is on the web too. There is also maintainer-scripts/update_web_docs_libstdcxx_git for libstdc++ docs. Jakub
[RISCV][CANCELED] RISC-V GNU Toolchain Biweekly Sync-up call (Oct 7, 2021)
Hi all, FYI The next RISC-V GNU Toolchain Biweekly Sync is cancelled because the developers from mainland China are still on their National Holiday. There were not too much new topics in the past weeks, except a few psABI issues, which could be postponed to the next meeting. -- Best wishes, Wei Wu (吴伟)
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 06, 2021 at 05:41:07PM +0200, Jakub Jelinek wrote: > On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote: > > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote: > > > >That means flipping the default on all PowerPC to no longer be double- > > > >double. This means that you should have IEEE QP work everywhere, or the > > > >people who do need more than double precision will have no recourse. > > > > > > I think we can exclude big-endian POWER from this - they do not have > > > IEEE QP support, correct? So, exclude that from the SONAME change. > > > > Not correct, no. IEEE QP works fine in either endianness. > > But only for Power8 or later, no? I guess the reason why le can switch > moreless easily (well, far from it, it is terribly hard anyway) is that > power8 is the oldest supported ISA for le, while be can't really assume > power8 or later. Yes. We can emulate it everywhere (using libquadmath for example). This can magically make -msoft-float work as well everywhere, btw. > Also, seems e.g. glibc support is there only for ppc64le and not be: > find . -name libm.abilist | xargs grep sinieee128 > ./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 > __asinieee128 F > ./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 > __casinieee128 F > ./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 > __csinieee128 F > ./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 > __sinieee128 F I don't know what the glibc situation is. The libraries will naturally not invest their energy in making anything work if the compiler neglects it :-( Segher
Re: Including documentation files with gcc releases
On Wed, 6 Oct 2021 at 16:57, dimechc wrote: > > > > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, October 6th, 2021 at 2:50 PM, Jonathan Wakely > wrote: > > > > On Wed, 6 Oct 2021, 14:19 dimechc, wrote: >> >> I got the GCC 11.2 download, but cannot locate the doc directory used to >> produce the >> gcc documentation manuals. > > > > You still haven't said which documentation you're talking about. > > GCC has lots of documentation. All the sources should be in the release > tarball but if you can't tell us which docs you're talking about, we can't > point to the specific sources for those docs. > > It seems you haven't really looked very hard though. You should have grep and > find utilities that can help. > > Jakub directed me to gcc/doc/, gcc/*/*.texi, libstdc++-v3/doc/, lib*/*.texi, > ... > > I am more used to emacs, and the doc directory is easier to locate as it is a > top lever directory. So by "scrutinising" you just meant "looking at the names of the top-level directories". > The documentation I am referring to is the code provided in > > https://gcc.gnu.org/onlinedocs/11.2.0/ > > Do there exist other gcc-related documention files not present in the gcc > release? I am looking at gcc-11.2.0.tar.gz (2021-07-28 08:15 137M) ? Static pages on the website are not in the main source repo, and so are not in the release tarball. Pages such as https://gcc.gnu.org/gitwrite.html are in the separate wwwdocs repo, which the first link on that page leads to.
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 06, 2021 at 11:42:17AM -0400, David Edelsohn wrote:
> On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool
> wrote:
> >
> > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > > On 05.10.21 23:54, Segher Boessenkool wrote:
> > > >>There is also the issue of binary data. If some user has written
> > > >>out data in double double and wants to read it in as IEEE quad,
> > > >>the results are going to be garbage. Another option for CONVERT
> > > >>might be the solution to that, or, as you wrote, having a
> > > >>REAL(KIND=15). It should be inaccessible via SELECTED_REAL_KIND,
> > > >>though.
> > > >
> > > >That means flipping the default on all PowerPC to no longer be double-
> > > >double. This means that you should have IEEE QP work everywhere, or the
> > > >people who do need more than double precision will have no recourse.
> > >
> > > I think we can exclude big-endian POWER from this - they do not have
> > > IEEE QP support, correct? So, exclude that from the SONAME change.
> >
> > Not correct, no. IEEE QP works fine in either endianness.
>
> This needs to be described with more granularity. IEEE QP
> instructions work with either endianness.
>
> IEEE QP is enabled and supported for PPC64 LE Linux on Power. The
> transition is under discussion.
IEEE QP insns are enabled for BE as well:
powerpc64-linux-gcc -Wall -W -O2 -S qp.c -mcpu=power9
=== qp.c ===
#define QP _Float128
QP f(QP x) { return x*x; }
===
results in
.L.f:
xsmulqp 2,2,2
blr
> PPC64 BE Linux on Power does not define IEEE QP. The ABI could be
> updated and IEEE QP could be enabled, but PPC64 BE is not planning
> future releases from Linux distros.
This is a different thing: on BE (and on LE by default as well) we use
double-double for long double.
> IEEE QP for PPC64 FreeBSD on Power is an open question for the FreeBSD
> community.
Yes.
> AIX on Power will continue to use double-double long double format.
> GCC, LLVM, IBM Open XL and IBM XL compilers will continue to implement
> and support the double-double format on AIX.
Yes. But this wasn't about what to use for long double -- it was about
Fortran even :-)
The actual IEEE QP float types work fine on BE. I suspect they do on
AIX as well for that matter?
Fwiw, with -mcpu=power8 we get
.L.f:
mflr 0
xxlor 35,34,34
std 0,16(1)
stdu 1,-112(1)
bl __mulkf3
nop
addi 1,1,112
ld 0,16(1)
mtlr 0
blr
Segher
Including documentation files with gcc releases
-‐‐ Original Message ‐‐‐ On Wednesday, October 6th, 2021 at 4:10 PM, Jonathan Wakely wrote: > On Wed, 6 Oct 2021 at 16:57, dimechc dime...@protonmail.com wrote: > > > ‐‐‐ Original Message ‐‐‐ > > > > On Wednesday, October 6th, 2021 at 2:50 PM, Jonathan Wakely > > jwakely@gmail.com wrote: > > > > On Wed, 6 Oct 2021, 14:19 dimechc, dime...@protonmail.com wrote: > > > > > I got the GCC 11.2 download, but cannot locate the doc directory used to > > > produce the > > > > > > gcc documentation manuals. > > > > You still haven't said which documentation you're talking about. > > > > GCC has lots of documentation. All the sources should be in the release > > tarball but if you can't tell us which docs you're talking about, we can't > > point to the specific sources for those docs. > > > > It seems you haven't really looked very hard though. You should have grep > > and find utilities that can help. > > > > Jakub directed me to gcc/doc/, gcc//.texi, libstdc++-v3/doc/, lib*/*.texi, > > ... > > > > I am more used to emacs, and the doc directory is easier to locate as it is > > a top lever directory. > > So by "scrutinising" you just meant "looking at the names of the > > top-level directories". No, but there are lot of directories, but was unsure what is there and what isn't. Because I have built from source, I did not look at the build directory, but rather at the source. You know exactly how you set things up, so I asked. > > The documentation I am referring to is the code provided in > > > > https://gcc.gnu.org/onlinedocs/11.2.0/ > > > > Do there exist other gcc-related documention files not present in the gcc > > release? I am looking at gcc-11.2.0.tar.gz (2021-07-28 08:15 137M) ? > > Static pages on the website are not in the main source repo, and so > > are not in the release tarball. Pages such as > > https://gcc.gnu.org/gitwrite.html are in the separate wwwdocs repo, > > which the first link on that page leads to. Thanks for that.
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: > We can emulate it everywhere (using libquadmath for example). This can > magically make -msoft-float work as well everywhere, btw. Emulation is one thing, but another one is where are those __float128 or quad long double arguments and return values passed. On power8 le I think they are passed in VSX registers, aren't they? But are those available everywhere where ppc64 is supported? For ppc32 certainly not, I don't remember for ppc64. Sure, the ABI could say pass it in e.g. in a pair of integer registers... Jakub
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote: > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: > > We can emulate it everywhere (using libquadmath for example). This can > > magically make -msoft-float work as well everywhere, btw. > > Emulation is one thing, but another one is where are those __float128 or > quad long double arguments and return values passed. On power8 le I think > they are passed in VSX registers, aren't they? On BE just as well. And on 32 bit. > But are those available everywhere where ppc64 is supported? For ppc32 > certainly not, I don't remember for ppc64. You can use VSX registers on 32 bit just fine. > Sure, the ABI could say pass it in e.g. in a pair of integer registers... Or more, on 32-bit. It isn't very useful to try to optimise this, so it is easiest to just handle it the same as a struct for register passing. For 32-bit this means it then is passed and returned as a pointer, for the older 64-bit ABIs it means it is passed as two GPRs but returned as a pointer, and for the ELFv2 ABI (on both BE and LE) it means that it is passed as well as returned in two GPRs. Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 06, 2021 at 11:59:37AM -0500, Segher Boessenkool wrote: > On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote: > > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: > > > We can emulate it everywhere (using libquadmath for example). This can > > > magically make -msoft-float work as well everywhere, btw. > > > > Emulation is one thing, but another one is where are those __float128 or > > quad long double arguments and return values passed. On power8 le I think > > they are passed in VSX registers, aren't they? > > On BE just as well. And on 32 bit. > > > But are those available everywhere where ppc64 is supported? For ppc32 > > certainly not, I don't remember for ppc64. > > You can use VSX registers on 32 bit just fine. With -mvsx (or perhaps even -maltivec) sure, but if neither VSX nor Altivec ISA is there... And having the ABI for long double dependent on whether one uses -mvsx/-maltivec or not is a non-started. For generic vectors it is something we decided to be acceptable... Jakub
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, 6 Oct 2021, Jakub Jelinek via Gcc wrote: > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: > > We can emulate it everywhere (using libquadmath for example). This can > > magically make -msoft-float work as well everywhere, btw. > > Emulation is one thing, but another one is where are those __float128 or > quad long double arguments and return values passed. On power8 le I think > they are passed in VSX registers, aren't they? > But are those available everywhere where ppc64 is supported? For ppc32 > certainly not, I don't remember for ppc64. As noted in previous discussions, while the current GCC implementation requires VSX for _Float128 support, the registers used in the ABI are the same as AltiVec registers; it would be possible to implement support for _Float128 on all powerpc64 with AltiVec (most but not all 64-bit processors), using AltiVec registers in the ABI and being fully compatible with the ABI using VSX registers. > Sure, the ABI could say pass it in e.g. in a pair of integer registers... You'd need to decide whether you want the 64-bit BE ABI for _Float128 to be one that supports the type on all 64-bit processors (so pass in integer registers), or one that only supports it on processors with AltiVec but is more similar to the LE ABI (passing in AltiVec registers). And, then, decide the 32-bit ABIs (hard and soft float), if you want to support _Float128 there. And, then, do glibc changes, both to support _Float128 functions at all, and to support a different long double format if you wish to support changing the long double format for those ABIs. Note that the symbol versioning in glibc assumes that all libm functions either predate _Float128 support on all architectures (version of *f128 versions is FLOAT128_VERSION) or postdate it on all architectures (versions in math/Versions based on whenever that function was added to glibc; various *f64x functions, that alias *f128 when appropriate, are also hardcoded as GLIBC_2.27). So if someone adds _Float128 support to any glibc ABI that doesn't currently have it, they need to add support for new syntax in Versions files such as MAX (FLOAT128_VERSION, GLIBC_2.28), which describes the right symbol version for a _Float128 function added in 2.28, in the case where some architecture gets _Float128 support later than that. And likewise using LDBL_IBM128_VERSION for __*ieee128 aliases if you add support for it being used as a new long double format. And adding the support to glibc means increasing the minimum GCC version for building glibc for those ABIs to one that supports _Float128 for those ABIs. -- Joseph S. Myers jos...@codesourcery.com
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 6, 2021 at 12:21 PM Segher Boessenkool
wrote:
>
> On Wed, Oct 06, 2021 at 11:42:17AM -0400, David Edelsohn wrote:
> > On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool
> > wrote:
> > >
> > > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > > > On 05.10.21 23:54, Segher Boessenkool wrote:
> > > > >>There is also the issue of binary data. If some user has written
> > > > >>out data in double double and wants to read it in as IEEE quad,
> > > > >>the results are going to be garbage. Another option for CONVERT
> > > > >>might be the solution to that, or, as you wrote, having a
> > > > >>REAL(KIND=15). It should be inaccessible via SELECTED_REAL_KIND,
> > > > >>though.
> > > > >
> > > > >That means flipping the default on all PowerPC to no longer be double-
> > > > >double. This means that you should have IEEE QP work everywhere, or
> > > > >the
> > > > >people who do need more than double precision will have no recourse.
> > > >
> > > > I think we can exclude big-endian POWER from this - they do not have
> > > > IEEE QP support, correct? So, exclude that from the SONAME change.
> > >
> > > Not correct, no. IEEE QP works fine in either endianness.
> >
> > This needs to be described with more granularity. IEEE QP
> > instructions work with either endianness.
> >
> > IEEE QP is enabled and supported for PPC64 LE Linux on Power. The
> > transition is under discussion.
>
> IEEE QP insns are enabled for BE as well:
>
> powerpc64-linux-gcc -Wall -W -O2 -S qp.c -mcpu=power9
>
> === qp.c ===
> #define QP _Float128
> QP f(QP x) { return x*x; }
> ===
>
> results in
>
> .L.f:
> xsmulqp 2,2,2
> blr
>
> > PPC64 BE Linux on Power does not define IEEE QP. The ABI could be
> > updated and IEEE QP could be enabled, but PPC64 BE is not planning
> > future releases from Linux distros.
>
> This is a different thing: on BE (and on LE by default as well) we use
> double-double for long double.
>
> > IEEE QP for PPC64 FreeBSD on Power is an open question for the FreeBSD
> > community.
>
> Yes.
>
> > AIX on Power will continue to use double-double long double format.
> > GCC, LLVM, IBM Open XL and IBM XL compilers will continue to implement
> > and support the double-double format on AIX.
>
> Yes. But this wasn't about what to use for long double -- it was about
> Fortran even :-)
>
> The actual IEEE QP float types work fine on BE. I suspect they do on
> AIX as well for that matter?
>
> Fwiw, with -mcpu=power8 we get
>
> .L.f:
> mflr 0
> xxlor 35,34,34
> std 0,16(1)
> stdu 1,-112(1)
> bl __mulkf3
> nop
> addi 1,1,112
> ld 0,16(1)
> mtlr 0
> blr
GCC can generate the IEEE QP instructions on AIX. The AIX Assembler
is aware of the instructions. libquadmath is neither built nor
installed on AIX. The AIX C library and AIX Math library are not
aware of the IEEE QP type nor how to work with it, e.g., printf.
Thanks, David
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 06, 2021 at 07:07:43PM +0200, Jakub Jelinek wrote: > On Wed, Oct 06, 2021 at 11:59:37AM -0500, Segher Boessenkool wrote: > > On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote: > > > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: > > > > We can emulate it everywhere (using libquadmath for example). This can > > > > magically make -msoft-float work as well everywhere, btw. > > > > > > Emulation is one thing, but another one is where are those __float128 or > > > quad long double arguments and return values passed. On power8 le I think > > > they are passed in VSX registers, aren't they? > > > > On BE just as well. And on 32 bit. > > > > > But are those available everywhere where ppc64 is supported? For ppc32 > > > certainly not, I don't remember for ppc64. > > > > You can use VSX registers on 32 bit just fine. > > With -mvsx (or perhaps even -maltivec) sure, but if neither VSX nor Altivec > ISA is there... This was for -mcpu=power8 only. And yes, you can use -mno-vsx if you have p8 or later, which gives us the same issues as -msoft-float. > And having the ABI for long double dependent on whether one uses > -mvsx/-maltivec or not is a non-started. For generic vectors it is > something we decided to be acceptable... This is not about long double. This is about IEEE quad precision float. We need to make that work (on system X) before we can fathom using IEEE QP float as long double on system X. Working out what the parameter passing should be like is independent of what type is used for long double. -msoft-float has been a separate ABI always, of course. And so far QP float has not existed for powerpc64-linux. So we have three options (well, four): 0) Do nothing. We will stay in this hell forever. Not my choice :-) 1) Use a soft-float-like parameter passing everywhere. This works but will be horridly slow on newer systems. We can do better than that. 2) Use the current setup where -mcpu=power8 (or later) makes QP float available. Most BE stuff isn't compiled with that currently, and it will split our ecosystem. 3) As Joseph reminds me the high VSRs are the VRs, so we could use the same parameter passing on anything with AltiVec. We could even simply require -maltivec for QP float to be supported (we currently require -mvsx, this would not be a restriction). I think I like 3) :-) Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 06, 2021 at 05:13:59PM +, Joseph Myers wrote: > On Wed, 6 Oct 2021, Jakub Jelinek via Gcc wrote: > > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: > > > We can emulate it everywhere (using libquadmath for example). This can > > > magically make -msoft-float work as well everywhere, btw. > > > > Emulation is one thing, but another one is where are those __float128 or > > quad long double arguments and return values passed. On power8 le I think > > they are passed in VSX registers, aren't they? > > But are those available everywhere where ppc64 is supported? For ppc32 > > certainly not, I don't remember for ppc64. > > As noted in previous discussions, while the current GCC implementation > requires VSX for _Float128 support, the registers used in the ABI are the > same as AltiVec registers; it would be possible to implement support for > _Float128 on all powerpc64 with AltiVec (most but not all 64-bit > processors), using AltiVec registers in the ABI and being fully compatible > with the ABI using VSX registers. Good point. And we can simply require -maltivec for -mfloat128 to work. We currently require -mvsx, which itself requires -maltivec, so that is not a restriction. > > Sure, the ABI could say pass it in e.g. in a pair of integer registers... > > You'd need to decide whether you want the 64-bit BE ABI for _Float128 to > be one that supports the type on all 64-bit processors (so pass in integer > registers), or one that only supports it on processors with AltiVec but is > more similar to the LE ABI (passing in AltiVec registers). I vote for the latter: require -maltivec. Well unless -msoft-float perhaps, if someone ever cares enough to implement that for QP float :-) > And, then, decide the 32-bit ABIs (hard and soft float), if you want to > support _Float128 there. Soft float is not described in any formal ABI btw (well, except the Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair. Which does not work over function calls, but that is how it always has been. This never was a huge problem afaik. For 32-bit, maybe we can just require -maltivec as well, to allow -mfloat128? Or use what -msoft-float would do for _Float128, if -mno-altivec, if desired (this does not have to be limited to -m32 of course). > And, then, do glibc changes, both to support _Float128 functions at all, > and to support a different long double format if you wish to support > changing the long double format for those ABIs. Note that the symbol > versioning in glibc assumes that all libm functions either predate > _Float128 support on all architectures (version of *f128 versions is > FLOAT128_VERSION) or postdate it on all architectures (versions in > math/Versions based on whenever that function was added to glibc; various > *f64x functions, that alias *f128 when appropriate, are also hardcoded as > GLIBC_2.27). So if someone adds _Float128 support to any glibc ABI that > doesn't currently have it, they need to add support for new syntax in > Versions files such as MAX (FLOAT128_VERSION, GLIBC_2.28), which describes > the right symbol version for a _Float128 function added in 2.28, in the > case where some architecture gets _Float128 support later than that. And > likewise using LDBL_IBM128_VERSION for __*ieee128 aliases if you add > support for it being used as a new long double format. And adding the > support to glibc means increasing the minimum GCC version for building > glibc for those ABIs to one that supports _Float128 for those ABIs. Glibc is outside of my direct influence sphere ;-) This does sound like a reasonable plan to me though. Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On 10/6/21 12:50 PM, Segher Boessenkool wrote: > So we have three options (well, four): > > 0) Do nothing. We will stay in this hell forever. Not my choice :-) > 1) Use a soft-float-like parameter passing everywhere. This works but >will be horridly slow on newer systems. We can do better than that. > 2) Use the current setup where -mcpu=power8 (or later) makes QP float >available. Most BE stuff isn't compiled with that currently, and it >will split our ecosystem. > 3) As Joseph reminds me the high VSRs are the VRs, so we could use the >same parameter passing on anything with AltiVec. We could even >simply require -maltivec for QP float to be supported (we currently >require -mvsx, this would not be a restriction). > > I think I like 3) :-) I like 3 too, meaning requiring -maltivec to support IEEE QP at all. This would cover POWER6 and later server CPUs, as well as some other cpus like in the Power Macs. Anything without Altivec hardware would need to either not support IEEE QP at all, or go through the work themselves of coming up with a -msoft-altivec like ABI. Peter
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, 6 Oct 2021, Segher Boessenkool wrote: > Soft float is not described in any formal ABI btw (well, except the > Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair. It's fully documented in the unified 32-bit ABI document (under ATR-SOFT-FLOAT conditionals). There's still some code in the compiler for a very old soft-float ABI for binary128 long double (passing by reference, using _q_* libcall names). I don't really think it makes much sense to use that for future _Float128 support for soft-float (certainly not the _q_* libcalls), rather than passing in four consecutive GPRs as is done for IBM long double for soft float, but we could. -- Joseph S. Myers jos...@codesourcery.com
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 06, 2021 at 07:42:31PM +, Joseph Myers wrote: > On Wed, 6 Oct 2021, Segher Boessenkool wrote: > > Soft float is not described in any formal ABI btw (well, except the > > Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair. > > It's fully documented in the unified 32-bit ABI document (under > ATR-SOFT-FLOAT conditionals). That doc calls itself "Power Architecture?? 32-bit Application Binary Interface Supplement 1.0 - Embedded". That is the exception I meant. Ignoring all the stuff I usually ignore it isn't very embedded, I agree, it is more or less what is powerpc-linux or powerpc-elf. With "not in any" I mean: not for other architectures either! All archs that do not say anything about floating point in their machine description get a working sofware floating point (for binary32 and binary64 currently). > There's still some code in the compiler for a very old soft-float ABI for > binary128 long double (passing by reference, using _q_* libcall names). I > don't really think it makes much sense to use that for future _Float128 > support for soft-float (certainly not the _q_* libcalls), rather than > passing in four consecutive GPRs as is done for IBM long double for soft > float, but we could. Maybe this harks back to POWER2 days? If so, we probably should just remove that code, we do not support anything else POWER2 anymore. If we want to implement soft-float for binary128, it would be best to do it the same for Power as for anything else. That of course means we have to *do* it for everything (or anything) else :-) And, as long as I'm creating more work, we could do binary16 and bfloat16 at the same time ;-) Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, 6 Oct 2021, Segher Boessenkool wrote: > > There's still some code in the compiler for a very old soft-float ABI for > > binary128 long double (passing by reference, using _q_* libcall names). I > > don't really think it makes much sense to use that for future _Float128 > > support for soft-float (certainly not the _q_* libcalls), rather than > > passing in four consecutive GPRs as is done for IBM long double for soft > > float, but we could. > > Maybe this harks back to POWER2 days? If so, we probably should just > remove that code, we do not support anything else POWER2 anymore. The _q_* names and associated ABI are in the 1995 SunSoft PowerPC ABI (which I suppose was the ABI for PowerPC Solaris). -- Joseph S. Myers jos...@codesourcery.com
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, 6 Oct 2021, Segher Boessenkool wrote: > With "not in any" I mean: not for other architectures either! All archs > that do not say anything about floating point in their machine > description get a working sofware floating point (for binary32 and > binary64 currently). Any architecture that supports a software floating-point ABI (i.e. one that does argument passing and return for floating-point in integer registers) should specify it in its ABI documents. For example, https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc describes both "Integer Calling Convention" and "Hardware Floating-point Calling Convention", with a series of named ABIs based on those such as LP64, LP64F, etc. (like on (32-bit) Arm, but unlike Power or MIPS, RISC-V GCC also supports building programs that use hardware floating-point instructions but the software floating-point ABI). That's how the (unified) 32-bit powerpc ABI documents things: both hardware and software floating-point ABI variants. If the architecture doesn't support hardware floating point, or doesn't have separate registers for it, the software floating-point ABI is just "the ABI" and there's no separate hardware floating-point ABI, of course. -- Joseph S. Myers jos...@codesourcery.com
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek wrote: > etc. Could we just pretend in the compiler to libgfortran ABI that > powerpc64le-linux real(kind=16) is kind 17 and make sure that if anything > would actually think it is 17 bytes it uses 16 instead (though, kind=10 > on x86-64 or i686 also isn't 10 bytes but 16 or 12, right?). > > Your thoughts on this? I tried this at one point. There are a lot of hidden assumptions that the kind number is the number of bytes. I'm sure it can be tracked down, but the problem is with these assumptions is you can't prove a negative (i.e. you never know that you've missed some). Note the PowerPC has a third configure option for long double with the configure option --without-long-double-128. This option makes long double on C/C++ be 64-bits instead of 128-bits. In terms of enabling IEEE outside of PowerPC 64 LE Linux systems there are two roadblocks: 1) The default configuration of BE systems is still Power4. You need at least Altivec registers to be able to pass and return IEEE 128-bit values. However, I am skeptical that configuring for a power6 could produce workable code, so power7 is the theoretical minimum that could be used. I limited it to power8 because the code needed direct moves and other ISA 3.0 support. PowerPC 64-bit LE has a minimum base level of power8, so it isn't an issue on that system. 2) The big stumbling block was that GLIBC only has IEEE 128-bit support for the LE systems. If there is BE glibc support, we could certainly add support for enabling IEEE 128-bit in BE systems if the compiler was configured for power8 or higher. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote: > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote: > > On 05.10.21 23:54, Segher Boessenkool wrote: > > >>There is also the issue of binary data. If some user has written > > >>out data in double double and wants to read it in as IEEE quad, > > >>the results are going to be garbage. Another option for CONVERT > > >>might be the solution to that, or, as you wrote, having a > > >>REAL(KIND=15). It should be inaccessible via SELECTED_REAL_KIND, > > >>though. > > > > > >That means flipping the default on all PowerPC to no longer be double- > > >double. This means that you should have IEEE QP work everywhere, or the > > >people who do need more than double precision will have no recourse. > > > > I think we can exclude big-endian POWER from this - they do not have > > IEEE QP support, correct? So, exclude that from the SONAME change. > > Not correct, no. IEEE QP works fine in either endianness. > > I don't know what the libraries do, but in GCC it works just fine. It only has the support if you add the options to enable IEEE 128-bit support when compiling programs. It is off by default. > > So this would only be critical for people on little-endian POWER8 > > who use double double. Hmm... can the POWER8 handle the IEEE QP > > instructions, or would that be trap and emulate? What is the > > plan there? > > The registers used by the QP insns are the VRs. Trying to use the QP > insns on a p8 will trap. There is no kernel emulation for them afaik. > > But, for p8 there is software emulation, that GCC can generate. This > follows the ABI as for p9 and later. If the code is compiled for power8, it always uses the software functions to do the support. Buried inside of libgcc are ifunc functions that use the hardware instructions if the user is running on power9 or power10. It would be nice if any distro that changed the default used power9 as a base, instead of power8. > Converting double-double to IEEE QP should not be hard or slow? There are a lot of corner cases to get it right. IIRC, there are a few values that double double can represent that are not expressable with exact precision in IEEE 128-bit. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On 07.10.21 05:35, Michael Meissner via Fortran wrote: I tried this at one point. There are a lot of hidden assumptions that the kind number is the number of bytes. I'm sure it can be tracked down, but the problem is with these assumptions is you can't prove a negative (i.e. you never know that you've missed some). So, summing up from the Fortran side, I'd say the best course of action is to - make KIND=16 into IEEE QP - bump the SONAME on on affected systems on POWER and nowhere else - have a preprocessor flag so we can #ifdef out code which is relevant only there - provide a CONVERT option (have to think of a suitable syntax) to do unformatted I/O either in IEEE QP or double double, but only on affected systems, so people can set this either via a CONVERT option on open or an environment variable. For OPEN, we should extend the existing one, for an environment variable, I'd say we should use a new one and reuse the existing parsing routines. Sounds like a reasonable minimum of user pain to me. The rest I'll leave to the experts in all things ABI and POWER :-)
