adc,sbb instruction intrinsics for arm?

[unlvsur unlvsur via Gcc]

I want that.


Sent from Mail for Windows

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Bill Schmidt via Gcc]

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 powerpc64le and GCC 12 from other topics like supporting more targets.

===

First, for the short-term.  For powerpc64le only (little-endian, ELFv2 ABI) 
Thomas suggested
that Fortran's best course of action is:
 - Change KIND=16 in GCC 12 from double-double to IEEE QP just for affected 
targets
 - Bump the SONAME just for affected targets
 - Have a preprocessor flag to help #ifdef out irrelevant code (which Jakub 
asserted exists)
 - Deal with binary (unformatted) I/O with a CONVERT option for OPEN, and/or an 
envvar, to
   allow selection between the two formats

There was some discussion of dual-mangling names for Fortran, but this didn't 
seem practical
because of a number of complicating factors.

There is an open question about possibly using KIND=15 or KIND=17 to represent 
double-double
going forward.  It's not clear whether or not this is necessary, but some C 
compatibility
scenarios were cited as possible motivations.

There was some concern about SONAME numbers differing across architectures, but 
consensus
seems to be that this can be handled.

Summary:  I didn't see any serious pushback to Thomas's suggested course of 
action, and the
only major open question is about maintaining a KIND to represent double-double.

===

Longer term, we have the question of supporting more Power targets.  AIX will 
continue to
use only double-double.  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.

[Sidebar: The ELFv1 document needs a new home, as the last version was 
published by the
now-defunct POWER.org.  But we can deal with that.]

Beyond ABI and compiler support, glibc would also need to support IEEE QP for 
these other
targets.  Currently we only have support for powerpc64le.

===

Is this a fair summary of the results of the discussion?

Thanks again!
Bill

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek via Gcc]

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.  I'd also like to separate out short-term 
> considerations
> for powerpc64le and GCC 12 from other topics like supporting more targets.
> 
> ===
> 
> First, for the short-term.  For powerpc64le only (little-endian, ELFv2 ABI) 
> Thomas suggested
> that Fortran's best course of action is:
>  - Change KIND=16 in GCC 12 from double-double to IEEE QP just for affected 
> targets
>  - Bump the SONAME just for affected targets
>  - Have a preprocessor flag to help #ifdef out irrelevant code (which Jakub 
> asserted exists)
>  - Deal with binary (unformatted) I/O with a CONVERT option for OPEN, and/or 
> an envvar, to
>allow selection between the two formats
> 
> There was some discussion of dual-mangling names for Fortran, but this didn't 
> seem practical
> because of a number of complicating factors.
> 
> There is an open question about possibly using KIND=15 or KIND=17 to 
> represent double-double
> going forward.  It's not clear whether or not this is necessary, but some C 
> compatibility
> scenarios were cited as possible motivations.
> 
> There was some concern about SONAME numbers differing across architectures, 
> but consensus
> seems to be that this can be handled.
> 
> Summary:  I didn't see any serious pushback to Thomas's suggested course of 
> action, and the
> only major open question is about maintaining a KIND to represent 
> double-double.
> 
> ===
...
> 
> Is this a fair summary of the results of the discussion?

For me yes.
As for a separate KIND!=16 for double-double, I've looked up Fortran 2018
standard wording and it seems that the ISO C Bindings actually don't require
such kind to exist, I believe
C_LONG_DOUBLE
should be -3 if -mabi=ibmlongdouble and we only support real KIND 4, 8 and
16 (last one IEEE quad), because it says that -3 stands for
"has neither the precision nor range" and 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 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 anything.
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.

Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Thomas Koenig via Gcc]

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 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 anything.
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.


There is one potential problem: selected_real_kind.

The standard says about that...

# If more than one kind type parameter value meets the criteria, the
# value returned is the one with the smallest decimal precision, unless
# there are several such values, in which case the smallest of these
# kind values is returned

So, selected_real_kind(25) would yield double double, and we would
have to violate the standard there if we wanted people to have
IEEE QP in that case.

Best regards

Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek via Gcc]

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 
> > anything.
> > 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.
> 
> There is one potential problem: selected_real_kind.
> 
> The standard says about that...
> 
> # If more than one kind type parameter value meets the criteria, the
> # value returned is the one with the smallest decimal precision, unless
> # there are several such values, in which case the smallest of these
> # kind values is returned
> 
> So, selected_real_kind(25) would yield double double, and we would
> have to violate the standard there if we wanted people to have
> IEEE QP in that case.

That would be true if some kind exist for double double, whether
it is kind == 15 or kind == 17, no?
Because precision (0.0_double_double_kind) < precision (0.0_ieee_quad_kind)
so the "smallest of the kind values" doesn't trigger.

Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Thomas Koenig via Gcc]

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 double-double nor range matches anything.
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.


There is one potential problem: selected_real_kind.

The standard says about that...

# If more than one kind type parameter value meets the criteria, the
# value returned is the one with the smallest decimal precision, unless
# there are several such values, in which case the smallest of these
# kind values is returned

So, selected_real_kind(25) would yield double double, and we would
have to violate the standard there if we wanted people to have
IEEE QP in that case.


That would be true if some kind exist for double double, whether
it is kind == 15 or kind == 17, no?


Correct.  The authors probably did not think of this particular
case when they wrote the standard.

We can ask the J3 standards committee to change the wording.  I think
I will just do that, to see what they have to say.

Best regards

Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

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

gcc-10-20211015 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20211015 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20211015/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision 762bb5baf8b04e91cc17aa9064648194263a34c7

You'll find:

 gcc-10-20211015.tar.xz   Complete GCC

  SHA256=30e37fb7a6638b6a5e1156525e1759c56fe80bb9aceeb8ad19a93433910033c0
  SHA1=e0ae6fedbe76025f39d835202c9f913a232dbd8f

Diffs from 10-20211008 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

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