On Mon, Nov 01, 2021 at 10:56:33AM -0500, Bill Schmidt wrote:
> Would starting from Advance Toolchain 15 with the most recent glibc make
> things easier for Thomas to test?
The problem is gcc135 runs Centos 7.x which is not compatible with AT 13-15.
--
Michael Meissner, IBM
PO Box 98, Ayer,
Would starting from Advance Toolchain 15 with the most recent glibc make things
easier for Thomas to test?
Thanks,
Bill
On 10/29/21 4:06 PM, Michael Meissner via Gcc wrote:
> On Fri, Oct 29, 2021 at 09:07:38PM +0200, Thomas Koenig wrote:
>> Hi Michael,
>>
>> I tried this out on the one POWER
Hi Jakub,
On Sat, Oct 30, 2021 at 11:30:29AM +0200, Thomas Koenig wrote:
- Have a compiler switch which selects between IEEE_QP and IBM_QP.
This was a suggestion by Steve Lionel formerly of DEC and Intel,
and they did that when they had a few floating point formats on
the Alpha to
On Sat, Oct 30, 2021 at 11:30:29AM +0200, Thomas Koenig wrote:
> - Have a compiler switch which selects between IEEE_QP and IBM_QP.
> This was a suggestion by Steve Lionel formerly of DEC and Intel,
> and they did that when they had a few floating point formats on
> the Alpha to choose from.
Hi Michael,
It adds target hooks so the back end can overwrite the kind number for types.
I made the IBM long double type use KIND=15 instead of KIND=16, and Float128
uses KIND=16 as we've discussed. The tests for long double are still
failing, so I suspect we will need some way of
This patch replaces the first patch.
Instead of disallowing long double and only dealing with float128 types, this
patch tries to accommodate the two.
It adds target hooks so the back end can overwrite the kind number for types.
I made the IBM long double type use KIND=15 instead of KIND=16, and
On Fri, Oct 29, 2021 at 11:21:33PM +0200, Bernhard Reutner-Fischer wrote:
> Michael,
>
> On Thu, 28 Oct 2021 23:36:20 -0400
> Michael Meissner via Fortran wrote:
>
> ISTM the second
> @defmac FORTRAN_USE_LONG_DOUBLE
> in tm.texi.in should be FORTRAN_USE_FLOAT128
Thanks. I had noticed that
On Fri, Oct 29, 2021 at 09:07:38PM +0200, Thomas Koenig wrote:
> Hi Michael,
>
> I tried this out on the one POWER machine where I can get something
> installed :-) It runs Ubuntu 20.04, but does not appear to have the
> right glibc version; it has
>
> $ lsb_release -a
> No LSB modules are
Michael,
On Thu, 28 Oct 2021 23:36:20 -0400
Michael Meissner via Fortran wrote:
ISTM the second
@defmac FORTRAN_USE_LONG_DOUBLE
in tm.texi.in should be FORTRAN_USE_FLOAT128
thanks,
Hi Michael,
I tried this out on the one POWER machine where I can get something
installed :-) It runs Ubuntu 20.04, but does not appear to have the
right glibc version; it has
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04.1 LTS
Release:
Here are the patches I worked on today. It does seem to fix KIND=16 to use
Float128, but by not considering long double for KIND processing, it breaks the
tests that want to do ISO C binding to long double.
Feel free to completely ignore the patches and go off in a different
direction. But I
I've played with some patches to PowerPC to set the defaults for fortran. But
without doing a full rebuild like you would do with a new distribution, I think
it will be problematical, unless you build everything with the default long
double set to IEEE 128-bit.
First off all, libquadmath is
On Fri, 15 Oct 2021, Bill Schmidt via Gcc wrote:
> Beyond ABI and compiler support, glibc would also need to support IEEE
> QP for these other targets. Currently we only have support for
> powerpc64le.
And that would involve new syntax in glibc Versions files, as discussed in
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 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
On 15.10.21 20:11, Jakub Jelinek wrote:
On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote:
with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble
33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither
precision of C long double if it is
On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote:
> > with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble
> > 33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither
> > precision of C long double if it is double-double nor range matches
> >
On 15.10.21 16:20, Jakub Jelinek wrote:
[...]
when one compiles
integer function foo ()
foo = precision (0.0_16)
end function foo
integer function bar ()
bar = range (0.0_16)
end function bar
with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble
33 and 4931. The
On Fri, Oct 15, 2021 at 08:50:08AM -0500, Bill Schmidt wrote:
> Thanks, Jakub, for starting this discussion, and to everyone who weighed in.
> The conversation
> went in a number of different directions, so I'd like to summarize my
> understanding of points
> where I think there was agreement.
Thanks, Jakub, for starting this discussion, and to everyone who weighed in.
The conversation
went in a number of different directions, so I'd like to summarize my
understanding of points
where I think there was agreement. I'd also like to separate out short-term
considerations
for
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.
>
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
On 10/5/21 12:43 PM, Segher Boessenkool wrote:
> 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
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
* Andreas Schwab:
> On Okt 09 2021, Thomas Koenig via Fortran wrote:
>
>> There is no choice - we need to make object code compiled by the user
>> incompatible between the old and the new format on the systems where
>> we make the switch.
>
> If you link, but not recompile, object files compiled
> On 9 Oct 2021, at 10:11, Thomas Koenig wrote:
>
>
> On 09.10.21 01:18, Iain Sandoe wrote:
>>> I meant the case where the user writes, with an old, KIND=16 is double
>>> double compiler,
>>>
>>> subroutine foo(a)
>>>real(kind=16) :: a
>>>a = a + 1._16
>>> end subroutine foo
>>>
On Sat, Oct 09, 2021 at 11:11:51AM +0200, Thomas Koenig wrote:
> The question is still if we can avoid a new SONAME for >99% of our users
> for no gain at all for them. Is there a possibility of aliasing the
> SONAME somehow (grasping at straws here)?
I'd hope Debian can just
ln -sf
On 09.10.21 01:18, Iain Sandoe wrote:
I meant the case where the user writes, with an old, KIND=16 is double
double compiler,
subroutine foo(a)
real(kind=16) :: a
a = a + 1._16
end subroutine foo
and puts it in a library or an old object file, and in new code with an
IEEE QP
On Okt 09 2021, Thomas Koenig via Fortran wrote:
> There is no choice - we need to make object code compiled by the user
> incompatible between the old and the new format on the systems where
> we make the switch.
If you link, but not recompile, object files compiled against different
versions
> On 8 Oct 2021, at 23:55, Thomas Koenig via Gcc wrote:
>
>
> Hi Iain,
>
>>> Things get interesting for user code, calling a routine compiled
>>> for double double with newer IEEE QP will result in breakage.
>> That would not happen with the proposal above, since the library would
>> have
Hi Thomas,
recognising that this is complex - the intent here is to see if there are ways
to partition the problem (where the pain falls does depend on the choices
made).
perhaps:
*A library (interface, name)
*B compiler internals
*C user-facing changes
> On 8 Oct 2021, at 17:26, Thomas
Hi Iain,
Things get interesting for user code, calling a routine compiled
for double double with newer IEEE QP will result in breakage.
That would not happen with the proposal above, since the library would
have different entry points for the two formats.
I meant the case where the user
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
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
Hi Iain,
If one wanted to prioritize library SO name stability - then, perhaps, the
approach Jonathan mentioned has been used for libstdc++ (add new
symbols for ieee128 with a different mangling to the existing r/c_16 ..)
would be preferable (the FE then has to choose the relevant symbol/
> On 8 Oct 2021, at 07:35, Thomas Koenig via Fortran
> wrote:
>
>
> On 07.10.21 17:33, Jakub Jelinek wrote:
>>> It will also be a compatibility issue if users have code compiled on a LE
>>> system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.
>> libgfortran ABI changed
On 07.10.21 17:33, Jakub Jelinek wrote:
It will also be a compatibility issue if users have code compiled on a LE
system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.
libgfortran ABI changed multiple times in the past already, e.g. the
so.1 -> so.2 transition in 4.2
so.2
On Thu, Oct 07, 2021 at 11:24:35AM -0400, Michael Meissner wrote:
> On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> > 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
On 07/10/2021 11:01, Jakub Jelinek wrote:
On Thu, Oct 07, 2021 at 11:56:45AM +0200, Andreas Schwab wrote:
On Okt 07 2021, Alastair McKinstry wrote:
I strongly advise against this -- identical SONAMEs for the libraries on
all architectures is a key assumption on all Debian-based
On Thu, Oct 07, 2021 at 11:56:45AM +0200, Andreas Schwab wrote:
> On Okt 07 2021, Alastair McKinstry wrote:
>
> > I strongly advise against this -- identical SONAMEs for the libraries on
> > all architectures is a key assumption on all Debian-based distributions
> > and designs
>
> Even glibc
On Okt 07 2021, Alastair McKinstry wrote:
> I strongly advise against this -- identical SONAMEs for the libraries on
> all architectures is a key assumption on all Debian-based distributions
> and designs
Even glibc has differing sonames on some architectures. And libgcc_s,
too.
Andreas.
--
On 06/10/2021 07:59, Thomas Koenig via Fortran wrote:
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
On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> 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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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.
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
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
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
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
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
On Mon, 4 Oct 2021, 15:14 Jakub Jelinek via Gcc, wrote:
> On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek via Gcc wrote:
> > Or the last option would be to try to make libgfortran.so.5 ABI
> compatible
> > with both choices on powerpc64le-linux. From quick skimming of
> libgfortran,
> >
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
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
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
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
>
On Mon, 4 Oct 2021, Jakub Jelinek via Gcc wrote:
> 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,
On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek via Gcc wrote:
> Or the last option would be to try to make libgfortran.so.5 ABI compatible
> with both choices on powerpc64le-linux. From quick skimming of libgfortran,
> we have lots of generated functions, which use HAVE_GFC_REAL_16 and
>
On Mon, Oct 04, 2021 at 01:36:56PM +0200, Jakub Jelinek via Gcc wrote:
> On Mon, Oct 04, 2021 at 01:24:05PM +0200, Richard Biener wrote:
> > > Your thoughts on this?
> >
> > How does glibc deal with this? There's a load of long double ABI in there.
>
> I don't know, CCing Florian; all I can see
On Mon, Oct 04, 2021 at 01:24:05PM +0200, Richard Biener wrote:
> > Your thoughts on this?
>
> How does glibc deal with this? There's a load of long double ABI in there.
I don't know, CCing Florian; all I can see is that starting with glibc 2.26
in addition to sin{f,,l} there is also sinf128,
On Mon, Oct 4, 2021 at 12:08 PM Jakub Jelinek via Fortran
wrote:
>
> Hi!
>
> On powerpc64le-linux target, one can select between two incompatible
> long double formats (both of them are 16-byte), __ibm128 which is
> a sum of two doubles, and __float128 (note, not implemented through
>
Hi!
On powerpc64le-linux target, one can select between two incompatible
long double formats (both of them are 16-byte), __ibm128 which is
a sum of two doubles, and __float128 (note, not implemented through
libquadmath), which is IEEE754 quad format. The default for
long double can be selected
73 matches
Mail list logo
