From: Segher Boessenkool <segher@kernel•crashing.org>
To: Michael Ellerman <mpe@ellerman•id.au>
Cc: dan@danny•cz, daniel@octaforge•org,
amd-gfx@lists•freedesktop.org, tpearson@raptorengineering•com,
alexdeucher@gmail•com, linuxppc-dev@lists•ozlabs.org
Subject: Re: [PATCH] powerpc/64: Always build with 128-bit long double
Date: Tue, 4 Apr 2023 10:10:10 -0500 [thread overview]
Message-ID: <20230404151010.GC25951@gate.crashing.org> (raw)
In-Reply-To: <20230404102847.3303623-1-mpe@ellerman.id.au>
Hi!
On Tue, Apr 04, 2023 at 08:28:47PM +1000, Michael Ellerman wrote:
> The amdgpu driver builds some of its code with hard-float enabled,
> whereas the rest of the kernel is built with soft-float.
>
> When building with 64-bit long double, if soft-float and hard-float
> objects are linked together, the build fails due to incompatible ABI
> tags.
> Currently those build errors are avoided because the amdgpu driver is
> gated on 128-bit long double being enabled. But that's not a detail the
> amdgpu driver should need to be aware of, and if another driver starts
> using hard-float the same problem would occur.
Well. The kernel driver either has no business using long double (or
any other floating point even) at all, or it should know exactly what is
used: double precision, double-double, or quadruple precision. Both of
the latter two are 128 bits.
> All versions of the 64-bit ABI specify that long-double is 128-bits.
> However some compilers, notably the kernel.org ones, are built to use
> 64-bit long double by default.
Mea culpa, I suppose? But builddall doesn't force 64 bit explicitly.
I wonder how this happened? Is it maybe a problem in the powerpc64le
config in GCC itself? I have a patch from summer last year (Arnd's
toolchains are built without it) that does
+ powerpc64le-*) TARGET_GCC_CONF=--with-long-double-128
Unfortunately I don't remember why I did that, and I never investigated
what the deeper problem is :-/
In either case, the kernel should always use specific types, not rely on
the toolchain to pick a type that may or may not work. The correct size
floating point type alone is not enough, but it is a step in the right
direction certainly.
Reviewed-by: Segher Boessenkool <segher@kernel•crashing.org>
Segher
next prev parent reply other threads:[~2023-04-04 15:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-04 10:28 [PATCH] powerpc/64: Always build with 128-bit long double Michael Ellerman
2023-04-04 15:10 ` Segher Boessenkool [this message]
2023-04-05 5:32 ` Michael Ellerman
2023-04-05 11:04 ` Segher Boessenkool
2023-04-06 17:12 ` Hamza Mahfooz
2023-04-12 12:34 ` Michael Ellerman
2023-04-26 12:01 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230404151010.GC25951@gate.crashing.org \
--to=segher@kernel$(echo .)crashing.org \
--cc=alexdeucher@gmail$(echo .)com \
--cc=amd-gfx@lists$(echo .)freedesktop.org \
--cc=dan@danny$(echo .)cz \
--cc=daniel@octaforge$(echo .)org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=mpe@ellerman$(echo .)id.au \
--cc=tpearson@raptorengineering$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox