Re: Proposal to switch powerpc64le to IEEE-754 binary128

Piotr Kubaj <[email protected]> Thu, 11 Jun 2026 23:42:32 +0200
Newsgroups gmane.os.freebsd.devel.ppc
Message-ID <aisryP-p7vz96Ui-@talos-powerpc64le>
--ocEJ/YwSIXe3Vz2b
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 26-06-11 09:54:09, Adrian Chadd wrote:
> On Thu, 11 Jun 2026 at 01:22, Piotr Kubaj <[email protected]> wrote:
> >
> > On 26-06-10 18:53:11, Adrian Chadd wrote:
> > > So, a few of us chatted in IRC about it.
> > >
> > > * The minimum for PPC64LE was POWER7 anyway, right?
> > POWER8. Last I heard, POWER7 has issues with unaligned access, which is
> > vital on LE. All the toolchains assume POWER8 as given on ppc64le.
> > > * There's no easy way to deal with this in library versioning and
> > > such, so we should just rip the bandaid off
> > > * We can fix the ports as they come up.
> > Yes, and there's not much to fix. The good news is that reinstallation
> > won't be necessary, upgrade is just the usual buildworld + installworld.
> > > * people wishing to run stuff built on -15 or earlier should just run
> > > a userland jail.
> > >
> > > so given that!
> > >
> > > * Please include something to propose to put in UPDATING
> > The review at https://reviews.freebsd.org/D57388 includes UPDATING
> > entry.
> > > * Please explain what will happen with all the toolchains in -HEAD (eg
> > > all the gcc versions will use the right base type, we won't have gcc
> > > compiling a different ABI to llvm21, etc)
>=20
> > Compilers explicitly using C's long double will need updating.
> > Everything else will work as it is. I have tested bootstraps for Rust,
> > GHC, OpenJDK and SBCL - all of them work. GCC and LLVM will need to be
> > updated though to emit correct long double, otherwise code built with
> > them that also uses long double type will misbehave. I'm also currently
> > playing with ldc and it will also need to be updated.
>=20
> Ok, can you go investigate GCC and LLVM too?
The clang part of our FreeBSD patch will be upstreamed and can be
readily backported to our ports.

Regarding GCC, there's a configure option for IEEE long double, so we
would be modifying just a port's Makefile.
>=20
> And go, maybe? Does go currently work on ppc64le?

Go doesn't work, there's a ready patch from Raptor that upstream somehow
isn't willing to merge. Raptor is apparently working on it. I have no
idea whether Raptor's patch will need modifications.
>=20
> > > * Let's figure out when the flag day should be.
>=20
> > Since it's CURRENT, people should expect breakages, we can't provide
> > stability there. IMO it's better to do it sooner than later so that more
> > people can test it. If someone doesn't want to upgrade yet, we're not
> > Microsoft, we don't force upgrades.
>=20
> Hey if you're willing to drive it forward then great! We just need to mak=
e sure
> it gets done enough that we don't end up with half working toolchains in =
ports.
Hmmm, I pretty often do bulk port builds anyway, just usually not
CURRENT, because with debugging enabled it takes a lot of time (and I
prefer to keep it enabled because it's CURRENT). I guess after the
switch I'll run CURRENT builds more often.
>=20
>=20
>=20
> -adrian
>=20

--ocEJ/YwSIXe3Vz2b
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQJPBAABCAA5FiEEycyIeNkkgohzsoorelmbhSCDnJ0FAmorK8UbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMCwyAAoJEHpZm4Ugg5ydQEIQAKi8OpB9DFYETC05DyzX
l1TChor7pcsQ7e94qJcJ49EG6aLaKzJMRgDbRdpaRgjxn7k6a1hxwgueeL5GFD7o
iyINOrgBM9plEewZQdP9bJLIOcLaGITK8YfvmyQm5q/KfApANnoEjUgL1bsZzYVF
47gVfFPRmw5DnhCdu3NTMOJxXXohRTiKqQd2tAjIdZ7WwvjLpSUAlVemApcokI95
s/iGhd86J9rrWih4wI6wxfQoFGjYaWq7N4SVJljqsLrkV44HYGbtxH8zldybem3u
fUMKR+voC4rzzGqD38x19RR9szb6ngkzFhd6LMXe/vi9IDT9cC9tYkp4gYfuL4uf
j52LiSeSyOnsIkKUqJRgNZAlHwbtKfn+PgfNNgJJZcAKGJntLiwF0lUt+OL8nXfb
ye9nTh4pFF4BaIYuYR2mAfTID4g4yPZu3rl30kxFrxK0WBPQH6jME3Tliv4Ia1sG
SgAXXgWnqZC4gNDJWlgbM/6uuWKPNrSM8iWGJT7WwVFYsAlNuhlNf+ianw/6zybU
AOqIP2XwzUK7oM9ocDWima3DoYpnmoQwL51ZoDmmvSX9TL6bRcCRvcFUV+WJ9fDy
KOYf/rniS5uM5XFc5Jwm2VlqGoN/Nkn6WUekBYFfryLsdqTJ660gD278jO/piYbL
5sSQZ8s7NaQSduDVk4s43MDA
=4Agt
-----END PGP SIGNATURE-----

--ocEJ/YwSIXe3Vz2b--