I want to discuss changes that I think we need to make across the open source
toochain to allow us to change the long double type on PowerPC hardware from
using the IBM extended double (i.e. a pair of doubles) to the IEEE 128-bit
format defined in IEEE 754.
I wasn't sure whom to address this to, s
One issue with doing the transition is what mangling should be used with the
new long double.
At the moment, the current mangling is:
long double "g"
__float128 "u9__ieee128"
__ibm128"g"
Obviously this will have to change in the future. It is unfortunate
On Sat, Aug 08, 2020 at 03:33:51PM +0200, Thomas König wrote:
> Hi Michael,
>
> I have shortened the distribution list somewhat for the Fortran-relevant
> parts.
>
> >I want to discuss changes that I think we need to make across the open source
> >toochain to allow us to change the long double ty
On Wed, Sep 09, 2020 at 02:42:36PM +0100, Jonathan Wakely wrote:
> Sorry for the slow reply to this.
>
> On Fri, 7 Aug 2020 at 22:14, Michael Meissner wrote:
> >
> > One issue with doing the transition is what mangling should be used with the
> > new long double.
> >
> > At the moment, the curren
I posted version 1 of the patches of the stuff needed to allow little endian
64-bit GCC on Linux to be configured to use long double.
As per the discussion in this thread, I did decide to keep things to two types
within the compiler. This means that an explicit __float128 or _Float128 will
use th
On Mon, Sep 28, 2020 at 04:38:51PM +, Joseph Myers wrote:
> On Thu, 24 Sep 2020, Michael Meissner wrote:
>
> > As per the discussion in this thread, I did decide to keep things to two
> > types
> > within the compiler. This means that an explicit __float128 or _Float128
> > will
> > use the
On Tue, Sep 29, 2020 at 05:34:55PM +0100, Jonathan Wakely wrote:
> On Mon, 28 Sep 2020 at 23:15, Joseph Myers wrote:
> >
> > On Mon, 28 Sep 2020, Michael Meissner via Gcc wrote:
> >
> > > > I'm not sure which patch in the series is supposed to be implemen
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 i
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 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 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 curre
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 tho
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 availa
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 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, Mas
On Fri, Dec 03, 2021 at 08:57:54AM -0600, Bill Schmidt wrote:
> Hi!
>
> On 12/3/21 5:56 AM, Thomas Koenig wrote:
> >
> > Hi Jakub,
> >
> >> Note, we want to test both building gcc on ppc64le with older glibc
> >> and newer glibc (and that libgfortran will have the same ABI between both
> >> and on
On Sat, Dec 04, 2021 at 02:42:13PM +0100, Thomas Koenig wrote:
> On 04.12.21 11:29, Jakub Jelinek wrote:
> > If zlib devel isn't installed, drop --with-system-zlib option
> > or use --without-system-zlib.
> >
> > You've asked in another mail how to configure gcc to default to
> > -mabi=ieeelongdou
On Sun, Dec 05, 2021 at 12:16:38PM +0100, Thomas Koenig wrote:
>
> On 05.12.21 01:35, Peter Bergner wrote:
> > Instead of setting LD_LIBRARY_PATH=/home/tkoenig/lib64 could you try
> > setting it to LD_LIBRARY_PATH='$ORIGIN/lib64' instead? This would
> > allow the other system binaries to not find
On Mon, Dec 13, 2021 at 09:29:16PM +0100, Thomas Koenig wrote:
>
> Hi,
>
> looking at what the REAL(KIND=17) numbers should be compiled for, I see
> the following options that should be considered:
>
> a) xsaddqp and friends are not supported by the CPU; libquadmath should
>be called for all
On Sun, Jan 02, 2022 at 11:58:29PM +0100, Thomas Koenig wrote:
> Hi Michael,
>
> > If you are building libraries that contain modules with multiple long double
> > types, you must use the '-mno-gnu-attribute'. We also use the '-Wno-psabi'
> > option, which silences the warning that you are switch
Note, I tried to send this out before, but it didn't seem to go out. Sorry if
you got it twice.
Sorry for the scatter shot mail that covers C++, Objective C++, Glibc,
etc. developers, but I wanted to discuss and get buy-in on changes to the
PowerPC GCC compiler that I would like to do in the endl
On Thu, Aug 04, 2022 at 10:49:24AM +0200, Nathan Sidwell wrote:
> Not a problem. I don't think I have anything to add- I presume you've
> thought about (weak) aliases to deal with the problematic changes you
> mention towards the end?
I've thought about it. I know in the past we had weak aliases
This is the same message I sent out before. I'm resending it to include
libc-al...@sourceware.org in the To: list.
Sorry for the scatter shot mail that covers C++, Objective C++, Glibc,
etc. developers, but I wanted to discuss and get buy-in on changes to the
PowerPC GCC compiler that I would lik
On Thu, Aug 04, 2022 at 10:14:10PM +0100, Jonathan Wakely wrote:
> On Thu, 4 Aug 2022 at 18:58, Michael Meissner via Gcc wrote:
> >
> > On Thu, Aug 04, 2022 at 10:49:24AM +0200, Nathan Sidwell wrote:
> > > Not a problem. I don't think I have anything to add- I presu
On Thu, Aug 04, 2022 at 03:53:55PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Aug 04, 2022 at 01:48:51PM -0400, Michael Meissner wrote:
> > At the moment, GCC 12 on the server PowerPC systems supports multiple
> > 128-bit
> > floating point types:
> >
> > * _Float128 (in the C
25 matches
Mail list logo
