Re: [power-iee128] How to specify linker flags
Hi! On Mon, Jan 03, 2022 at 11:19:21AM +0100, Thomas Koenig wrote: > One additional point. The linker does not understand > -mno-gnu-attribute: That is a GCC option, not an ld one. If you use it to compile some file there will be no .gnu.attributes section generated for that translation unit. Segher
Re: [PATCH V2] powerpc: properly check for feenableexcept() on FreeBSD
Hi Piotr, On Tue, May 03, 2022 at 12:21:12PM +0200, pku...@freebsd.org wrote: > FreeBSD/powerpc* has feenableexcept() defined in fenv.h header. Declared, not defined. These are required to be real functions (on all platforms that have these functions), not macros or inlines or whatever. So what library *does* have these functions? It would be much neater to do the similar to the libm test but with that other library. Just libc, maybe? The answer to this will probably also answer Ke Wen's questions, or at least just point to a good and more general way of solving this :-) Maybe the AC_CHECK_LIB could just use GCC_CHECK_MATH_FUNC or such? You also need a changelog entry here. Something like 2022-05-12 Piotr Kubaj libgfortran/ * configure.ac (powerpc*-freebsd*): Define HAVE_FEENABLEEXCEPT if declares the feenableexcept function. * configure: Regenerate. > +case x$target in > + xpowerpc*-freebsd*) > +AC_CACHE_CHECK([for fenv.h and feenableexcept], have_feenableexcept, [ > + AC_COMPILE_IFELSE([AC_LANG_PROGRAM( > +[[ #include ]], > +[[ feenableexcept(FE_DIVBYZERO | FE_INVALID); ]])], > +[ have_feenableexcept="yes" ], > +[ have_feenableexcept="no" ])]) Please get rid of all surplus whitespace here. Imitate existing tests, if you need inspiration :-) Segher
Re: [PATCH V2] powerpc: properly check for feenableexcept() on FreeBSD
On Fri, May 13, 2022 at 12:34:05PM +0200, Piotr Kubaj wrote: > On 22-05-13 10:59:59, Kewen.Lin wrote: > > on 2022/5/13 04:16, Segher Boessenkool wrote: > > > On Tue, May 03, 2022 at 12:21:12PM +0200, pku...@freebsd.org wrote: > > >> FreeBSD/powerpc* has feenableexcept() defined in fenv.h header. > > > > > > Declared, not defined. These are required to be real functions (on all > > > platforms that have these functions), not macros or inlines or whatever. > > > > > > > Piotr's reply "FreeBSD doesn't have this function in libm, it's > > implemented in /usr/include/fenv.h." from [1] made me feel like > > it's a definition instead of declaration. So I thought the check > > should use AC_LINK_IFELSE instead, since one fenv.h which doesn't > > have the definition can still pass the proposed AC_COMPILE_IFELSE > > check. > > > > I just did a further search, the powerpc fenv.h [2] does include > > the definition of feenableexcept. By comparison, the x86 fenv.h [3] > > doesn't. But I'm not sure if it's the same as what Piotr's > > environments have. Hope it's similar. :-) > > > > [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593193.html > > [2] https://github.com/freebsd/freebsd-src/blob/main/lib/msun/powerpc/fenv.h > > [3] https://github.com/freebsd/freebsd-src/blob/main/lib/msun/x86/fenv.h > > Yes, it's a definition and thanks for confirming that. As for why it's not in > libm, I asked a developer about that: > 03:04 <@adalava> It shouldn't be difficulted but I moved to other thing after > months looking at FPE in kernel, bugs in context switch and msun test cases > failing :-P > > As far as I know, there are currently no plans to move it to libm on powerpc. > riscv, arm and arm64 are in the same boat. > > I will follow with a next patch that will check for feenableexcept() in > fenv.h if libm check is unsuccessful. FreeBSD's own documentation (<https://www.freebsd.org/cgi/man.cgi?query=feenableexcept>) says it is a function, and it suggests it is in the standard library even. This would be as expected, the same holds for the similar C standard functions. This does not provide an external definition, only a static inline (this is a good thing for a header file of course). You can take the address of a function. You also can interpose a real function normally, but that may not be relevant for FreeBSD, no idea. You can do neither with a static inline. So this should probably be fixed? Thanks for explaining the situation better! Segher
Re: Floating-point comparisons in the middle-end
On Thu, Sep 01, 2022 at 10:19:59AM +0200, Jakub Jelinek via Gcc wrote: > On Thu, Sep 01, 2022 at 10:04:58AM +0200, FX wrote: > > 2. All the functions are available as GCC type-generic built-ins (yeah!), > > except there is no __builtin_ iseqsig > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77928). Is there a > > fundamental problem with creating one, and could someone help there? > > IMHO until that one is implemented you can just use > tx = x, ty = y, tx>=ty && tx<=ty > (in GENERIC just SAVE_EXPR >= SAVE_EXPR && SAVE_EXPR <= SAVE_EXPR > PowerPC backend is still broken, not just for that but for most other cases > above, it doesn't violate just Fortran requirements, but C too. See my talk at the GCC cauldron 2019 (Montréal) for what needs to be done in the generic handling for us to be able to fix what the rs6000 backend does here. Segher
Re: [Patch] Testsuite/Fortran: gfortran.dg/pr96711.f90 - fix expected value for PowerPC [PR96983]
On Wed, May 19, 2021 at 02:32:02PM +0200, Tobias Burnus wrote:
> Regarding gfortran.dg/pr96711.f90:
>
> On my x86-64-gnu-linux, it PASSes.
> On our powerpc64le-linux-gnu it FAILS with
> 'STOP 3' (→ also scan-dump count) and 'STOP 4'.
>
> Contrary to PR96983's bug summary, I don't get an ICE.
>
>
> On powerpc64le-linux-gnu, the following condition evaluates true (→ 'STOP
> 3'):
>
>real(16) :: y ! 128bit REAL
>integer(16), parameter :: k2 = nint (2 / epsilon (y), kind(k2))
>integer(16), parameter :: m2 = 10384593717069655257060992658440192_16
>!2**113
>if (k2 /= m2) stop 3
>
> On x86_64-linux-gnu, k2 == m2 — but on powerpc64le-linux-gnu,
> k2 == 2**106 instead of 2**113.
>
> My solution is to permit also 2**106 besides 2**113.
>
> @PowerPC maintainers: Does this make sense? – It seems to work on our
> PowerPC
> but with all the new 'long double' changes, does it also work for you?
I do not understand Fortran well enough, could you explain what the code
is supposed to do?
> PR fortran/96983
> * gfortran.dg/pr96711.f90:
You're missing the actual entry here, fwiw.
> - integer(16), parameter :: m2 = 10384593717069655257060992658440192_16
> !2**113
> + integer(16), parameter :: m2 = 10384593717069655257060992658440192_16
> !2**113 ! Some systems like x86-64
> + integer(16), parameter :: m2a = 81129638414606681695789005144064_16
> !2**106 ! Some systems like PowerPC
If you use double-double ("ibm long double") a number is represented as
the sum of two double precision numbers, while if you use IEEE quad
precision floating point you get a 112-bit fraction (and a leading one).
The most significant of the two DP numbers is the whole rounded to DP.
The actual precision varies, it depends on various factors :-/
Segher
>integer(16), volatile :: m
>x = 2 / epsilon (x)
>y = 2 / epsilon (y)
>m = nint (x, kind(m))
> ! print *, m
>if (k1 /= m1) stop 1
>if (m /= m1) stop 2
>m = nint (y, kind(m))
> ! print *, m
> - if (k2 /= m2) stop 3
> - if (m /= m2) stop 4
> + if (k2 /= m2 .and. k2 /= m2a) stop 3
> + if (m /= m2 .and. m /= m2a) stop 4
> end program
Re: [Patch] Testsuite/Fortran: gfortran.dg/pr96711.f90 - fix expected value for PowerPC [PR96983]
Hi!
On Wed, May 19, 2021 at 08:35:26PM +0200, Tobias Burnus wrote:
> On 19.05.21 17:15, Segher Boessenkool wrote:
> >>real(16) :: y ! 128bit REAL
> >>integer(16), parameter :: k2 = nint (2 / epsilon (y), kind(k2))
> >>integer(16), parameter :: m2 = 10384593717069655257060992658440192_16
> >>!2**113
> >>if (k2 /= m2) stop 3
> >>
> >>On x86_64-linux-gnu, k2 == m2 — but on powerpc64le-linux-gnu,
> >>k2 == 2**106 instead of 2**113.
> >>
> >>My solution is to permit also 2**106 besides 2**113.
> >I do not understand Fortran well enough, could you explain what the code
> >is supposed to do?
>
> First, 2_16 means the integer '2' of the integer kind '16', i.e. int128_t
> type.
Ah ok.
> And I think this testcase tries to ensure that the result of 'nint'
> both at compile time and at runtime matches what should be the result.
That is the main thing I missed :-)
> ('a**b' is the Fortran syntax for: 'a' raised to the power of 'b'.)
I know, I use it all the time :-) Many other languages have this
nowadays btw. It is such a succinct notation :-)
> nint(2/epsilon(y)). Here, 'epsilon' is the
> "Model number that is small compared to 1."
> Namely: b**(p-1) = '(radix)**(1-digits)'
> alias 'real_format *fmt = REAL_MODE_FORMAT (mode)'
> with radix = fmt->b and digits = fmt->p;
>
> [b**(p-1) is from the Fortran standard but 'b' and 'p' also match the
> ME/target names, while radix/digits matches the FE names and also the
> Fortran intrinsic inquiry function names.]
>
> This is for radix = 2 equivalent to:
>
> 2/2**(1-digits) = 2*2**(digits-1) = 2**(digits)
>
> On x86-64, digits == fmt->p == 113.
And the same on powerpc64le with -mabi=ieeelongdouble, presumably.
> Our powerpc64le gives digits == 106.
It stil defaults to -mabi=ibmlongdouble.
> Having written all this, I wonder why we don't just
> rely on the assumption that '2**digit(x)' works – and use this
> to generate the valid.
If that works (and I have no reason to believe it won't), that is as
simple a solution as you will find :-)
> As I like that patch and believe it is obvious, I intent to
> commit it as such – unless there are further comments.
> It passes on both x86-64-gnu-linux and powerpc64le-none-linux-gnu.
> I think the radix == 2 is a good bet, but if we ever run into issues,
> it can also be changed to use radix(...) as well ...
I don't think any GCC target does 10 or 16 by default, and less chance
in Fortran even :-)
Thanks!
Segher
Re: [Patch v2 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.
Hi! On Tue, Aug 10, 2021 at 10:29:08AM +0200, Tobias Burnus wrote: > On 09.08.21 23:42, Sandra Loosemore wrote: > In terms of Fortran, REAL types do not need to follow IEEE > (there are IEEE intrinsic modules to handle IEEE); thus, REAL(16) > does not need to be an IEEE type – albeit most users implicitly > expect it. > > Likewise, kind numbers have no meaning, but there is plenty of > code which expects that kind=4 = 32bit and kind=8 = 64bit, > especially when used in older code as '*' (e.g. 'real*8') > but also quite some code using the newer syntax '()' or > '(kind=') (e.g. 'real(8)' or 'real(kind=8)'). > > For real, kind=10 (i387's 80bit type) is a specialty of gfortran > (most? all?) other compilers do not support it; kind=16 is more widely > supported, albeit some simply map it to 'long double'. So, make 16 always mean IEEE QP float for us, and 15 mean double-double? (Or whatever other number you prefer -- as you explain, 16 should be the preferred one though, and that is the IEEE float of course). > There is no reason why the different PowerPC TF modes couldn't be > mapped to, e.g., the kinds 17, 18, 19, 20 – except that the Fortran FE, > libgfortran current assumes that only 4, 8, 10 and 16 exist and if > 10 exists, 16 is the 'q'/libquadmath version. – Additionally, those > 17-20 kinds will also confuse users and using '16' has to be mapped > somehow to one of the TF modes in a way that it still works with > interface kind checks and .mod module files and PowerPC's -m flags. There are only two 16-byte float modes: IFmode is double-double, and KFmode is IEEE QP float. Those modes mean the same thing whatever options the compiler has, and whatever the default is. TFmode is another name for one of those two modes, and that one can vary. Also, of course, a mode is not a type, and a type is not a mode, they are different concepts. IEEE QP float is always available (if enabled) via __ieee128, and double-double is always available via __ibm128. > >code that initializes those constants is still buggy. The reason why > >it shouldn't support them is that all 3 128-bit floating-point modes > >on PowerPC would map onto kind=16, So fix that? 16 should be the IEEE kind, and then something else for the double-double kind? > Side note: in rs6000-modes.h, there is: > #define FLOAT_PRECISION_IFmode 128 > #define FLOAT_PRECISION_TFmode 127 > #define FLOAT_PRECISION_KFmode 126 > with IFmode (IBM 128-bit floating point), TFmode (long double mode), KFmode > (explicit __float128). This is a workaround for a fundamental problem in GCC internals, which requires all floating point modes to be ordered. This is not true for QP float and double-double: each of those can represent values the other can not. And it is only a workaround, and it will change some day. > >and we can only support one of them unless we make some exception to > >the formula for mapping precision -> kind. And the mode the Fortran > >front end already prefers is the one that corresponds to long double > >or TFmode. > I concur. A kind number should always map to the same floating point format, it should not depend on unrelated compiler flags. It should not matter at all what "long double" maps to. Anything else leads to more insanity than needed. Segher
Re: [Patch v3 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.
Hi! On Tue, Aug 10, 2021 at 04:46:11PM -0600, Sandra Loosemore wrote: > OK. I used your wording verbatim for the first one. For the second > one, I'm still pretty confused as I think it is at least theoretically > possible on PowerPC to have a target with 64-bit long double (AIX?) that Some embedded and embedded-like subtargets use 64-bit long double by default. You can also configure this on any Power target (not that it will necessarily work ;-) ) I don't know if any subtarget with default 64-bit long double supports Fortran. > also supports the __ibm128 format, and it would be wrong to assume that > *any* 128-bit mode that's not long double is IEEE. Absolutely. Modes are not types, and types are not modes. There are 128-bit floating point modes that are not IEEE, there are that are, and either can be used for long double, or neither. Segher
Re: [Patch v3 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.
Hi! On Wed, Aug 11, 2021 at 12:29:06PM +0100, Iain Sandoe wrote: > > On 11 Aug 2021, at 11:55, Segher Boessenkool > > wrote: > > On Tue, Aug 10, 2021 at 04:46:11PM -0600, Sandra Loosemore wrote: > >> OK. I used your wording verbatim for the first one. For the second > >> one, I'm still pretty confused as I think it is at least theoretically > >> possible on PowerPC to have a target with 64-bit long double (AIX?) that > > > > Some embedded and embedded-like subtargets use 64-bit long double by > > default. You can also configure this on any Power target (not that it > > will necessarily work ;-) ) > > > > I don't know if any subtarget with default 64-bit long double supports > > Fortran. > > I realize that this is not directly relevant to unscrambling the PPC 128bit > stuff, > but aarch64-apple-darwin2x has only 64b long double and supports gfortran. > (on both the new M1 desktop macOS and embedded iOS) Yes, but aarch64-apple-darwin2x is not an rs6000 subtarget :-) There certainly are many targets with a 64b long double. > - it is not clear to me yet if there will at some point be a transition to a > 128b >long double for at least the desktop version. Yeah. I recommend any new target (or target for which this is new) to use an IEEE QP float as long double, even if just as soft float -- the advantages are just too great. > So the permutation definitely exists for at least one non-legacy, non-embedded > platform (and gfortran is very much in demand from the new M1 users). M1 is not embedded? :-) Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
Hi! On Mon, Oct 04, 2021 at 04:14:10PM +0200, Jakub Jelinek 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. > libgfortran would then on powerpc64le-linux use -mabi=ieeelongdouble to make > sure that regardless of the long double choice for C/C++ (whether default > configure time selection or explicit -mabi=*) GFC_REAL_16 is the __float128 > long double. > One problem with that is that I think IEEE quad long double support relies > on glibc 2.32 or later, so not sure what exactly would be done if gcc is > built against older glibc when it needs to call libm routines. Perhaps > convert to __ibm128, call the __ibm128 sinl etc. and convert back (big loss > of precision and range, but at least something). Eventually we should get a world where kind=16 is IEEE QP float everywhere, and kind=17 (or whatever) is double-double. Some current Power GCC targets support neither. Some support only double-double. Making IEEE QP float work on those (that is, those that are < power8) will require some work still: it should use libquadmath or similar, but that needs to be put into the ABIs, to define how parameter passing works for those types. Just treating it like a struct or an array of ints will work fine, but it needs to be written down. This is more than just Fortran. Mike? Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
Hi Joseph, On Mon, Oct 04, 2021 at 07:24:31PM +, Joseph Myers wrote: > On Mon, 4 Oct 2021, Segher Boessenkool wrote: > > Some current Power GCC targets support neither. Some support only > > double-double. Making IEEE QP float work on those (that is, those that > > are < power8) will require some work still: it should use libquadmath or > > similar, but that needs to be put into the ABIs, to define how parameter > > passing works for those types. Just treating it like a struct or an > > array of ints will work fine, but it needs to be written down. This is > > more than just Fortran. > > Is the 64-bit BE (ELFv1) ABI maintained somewhere? (The 32-bit ABI, > covering both hard float and soft float, is > <https://github.com/ryanarn/powerabi> - no activity lately, but I think > Ryan said he'd given write access to someone still involved with Power.) The last release (version 1.9) was in 2004. If there is interest in making updates to it that coulde be done of course, it is GFDL, there is no red tape getting in the way. Maybe this could be maintained in the same repository even? Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
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. 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. 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. 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. Segher
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 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: 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
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 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 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, Oct 06, 2021 at 10:03:59PM +, Joseph Myers wrote: > 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). But many CPUs do not have hardware floating point in any variant, and their ABIs / calling conventions do not mention floating point at all. Still, this works with GCC just fine: it passes floats and doubles the same as 32-bit resp. 64-bit integers. binary16 and bfloat16 would be easy to support the same way, but it is a bit harder for binary128, because we do not have a 128-bit integer type on all systems. That should be fixed first probably. It doesn't have to be very good machine code, but having it supported everywhere would simplify things a lot. > That's how the (unified) 32-bit powerpc ABI documents things: both > hardware and software floating-point ABI variants. Yes. I am not saying this isn't good or desirable, but simply how things are now. > 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. Right, and many architectures neglect to even mention anything to do with floating point, although this is and always was a standard C feature :-/ Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Wed, Oct 06, 2021 at 11:42:11PM -0400, Michael Meissner 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: > > > 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. You need -mvsx and -mfloat128, both on by default on power7 and later. Without hardware QP support it will call __mulkf3 and friends. But the parameter passing is identical: in the high VSRs (i.e. the VRs). There are no differences between BE and LE here. > > 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. Yes, but those are trivial to get right. The value of a double-double is the sum of both doubles. The sign is the sign of the first component though (which matters if adding -0. and +0.), that is all, all other cases magically work out as wanted afaics. Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
Hi! On Mon, Oct 11, 2021 at 08:11:50PM +, Joseph Myers wrote: > On Fri, 8 Oct 2021, Segher Boessenkool wrote: > > But many CPUs do not have hardware floating point in any variant, and > > their ABIs / calling conventions do not mention floating point at all. > > Still, this works with GCC just fine: it passes floats and doubles the > > same as 32-bit resp. 64-bit integers. > > > > binary16 and bfloat16 would be easy to support the same way, but it is a > > bit harder for binary128, because we do not have a 128-bit integer type > > Supporting passing arguments (and return values) the same as an integer > type of the same size is a *choice* (which comes with other choices - in > particular, whether to say some or all the higher bits in the register or > stack slot are sign-extended, zero-extended or undefined). It's a choice > that should be made explicitly, and documented (in the relevant ABI if one > is maintained), and coordinated between implementations when there's more > than one implementation for the architecture trying to be compatible. I don't disagree at all. But: GCC makes that choice for you, if you do not. Many (embedded and/or older) targets do not. They get the defaults, those just work, and /de facto/ become the standard. In practice most such architectures are purely 32-bit, so there is no sign/zero extension problem. > We've had plenty of problems in the past with ABIs that were just what > happened to fall out of the implementation (e.g. ABIs that depended on the > details of what machine mode was assigned to a structure type...). Yes. And we still have problems on older ABIs with e.g. new C++ requirements that did not exist >25 years ago when the ABIs were written. Not all of this can be helped at all. > On a related note, I'd encourage architecture maintainers to start > thinking now about what exactly their ABIs should be for _BitInt > (<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf>, accepted as > a required feature for C23 up to at least the width of unsigned long > long), and documenting it and coordinating with other implementations > where appropriate. There's a concrete proposal for x86_64 (see > origin/usr/hjl/bitint branch at > https://gitlab.com/x86-psABIs/x86-64-ABI.git) that may at least help as an > indication of the sort of issues to address in such an ABI. This should really go on gcc@, in a thread of its own, and a wiki page might help as well? Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Thu, Oct 14, 2021 at 02:39:47PM -0500, Bill Schmidt wrote: > On 10/5/21 12:43 PM, Segher Boessenkool wrote: > > The last release (version 1.9) was in 2004. If there is interest in > > making updates to it that coulde be done of course, it is GFDL, there is > > no red tape getting in the way. > > > > Maybe this could be maintained in the same repository even? > > Well, I'm not sure it's quite this easy; when developing ELFv2, there was > enough > doubt about the provenance/ownership of ELFv1 that we weren't comfortable > borrowing > language from it. That may have been an excess of caution, or it may not... I am not suggesting you should share this text with some other ABI. Just that you can put it in the same repository :-) > That said, with enough diligence I would hope we would be able to create > modifications to the ELFv1 document, but we might incur some paperwork. It is GFDL version 1.1 . The hardest part should be to find that older licence version :-P (<https://www.gnu.org/licenses/old-licenses/fdl-1.1.en.html> fwiw) (But I understand your situation, heh. Let the lawyers worry about it? That is their job :-) ) Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Fri, Oct 15, 2021 at 04:20:49PM +0200, Jakub Jelinek wrote: > If we do implement double-double support, I think KIND=15 would be better > than KIND=17, it is true that double-double has for certain numbers much > higher precision than IEEE quad, but the precision depends on the numbers > and most of the time is smaller, the range is always smaller. And > the PRECISION/RANGE intrinsic numbers are also both smaller. Yes. We want KIND=16 to mean the IEEE QP format whenever we can, right? And another 16-byte format would more logically be kind=17 then, considering we want to have two 2-byte kinds at least, one of them IEEE as well. Other practical considerations might well supersede elegance of course. Segher
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
Thank you for writing this out Bill! On Fri, Oct 15, 2021 at 08:50:08AM -0500, Bill Schmidt wrote: > Longer term, we have the question of supporting more Power targets. AIX will > continue to > use only double-double. Yes. So it will be virtually no cost to continue supporting double-double on all targets (implementation cost that is -- maintenance cost will actually be negative for keeping it for a while, old data sticks around for a very long time.) > It is agreed that it would be useful for 32- and 64-bit BE Linux > to support IEEE QP as well, on some future timeline. The first step towards > this is to > develop and document ABI for IEEE QP on those targets. The simplest approach > that everyone > seemed to like is for these ABIs to require AltiVec support in order for IEEE > QP to be > supported. This allows parameters and return values to always be passed in > vector registers, > whether implemented with hardware instructions or a soft-float library. > libquadmath can > be built for these targets. This is a great choice for the ABIs that have AltiVec enabled, yes. It requires almost no modification to the parameter passing for them (ignoring the obvious fact that it changes where long double is passed, if long double now is IEEE QP; similarly, KIND=16), it can be just the same as anything else passed in VRs. At a later date we can consider having QP for ABIs without AltiVec as well, if there is any interest in that. Since there exists no such thing yet, having QP passed in VRs will be easy to do everywhere :-) Segher
Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes
On Mon, Nov 15, 2021 at 06:42:18PM -0500, Michael Meissner wrote: > > I assume we would to the development on a branch. My git fu > > is extremely weak, so I would appreciate if somebody did that > > for me. > > Sure, we can create an IBM vendor branch. It should not be an IBM branch, we should not mix that with community stuff. Instead it should be in devel/. I'll create it, but someone needs to come up with a good name. Something better than the "kind16" I would do ;-) Segher
Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes
On Fri, Nov 19, 2021 at 01:36:33PM -0600, Peter Bergner wrote: > On 11/19/21 1:09 PM, Thomas Koenig wrote: > >> On Mon, Nov 15, 2021 at 06:42:18PM -0500, Michael Meissner wrote: > >>> Sure, we can create an IBM vendor branch. > >> > >> It should not be an IBM branch, we should not mix that with community > >> stuff. Instead it should be in devel/. > > Agreed, this would be better as a normal devel branch. > > > >> I'll create it, but someone needs to come up with a good name. > >> Something better than the "kind16" I would do ;-) > > > > power-ieee128, maybe? I do not think we need to adhere to the > > somewhat outdated "rs6000" name :-) > > Or how about gfortran-ieee128? I have created devel/power-ieee128. Descriptive names are good, but so are shorter names. Segher
