Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx> writes: > 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. In a perfect world ... :) >> 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? Not blaming anyone, just one of those things that happens. The toolchains the distros (Ubuntu/Fedora) build all seem to use 128, but possibly that's because someone told them to configure them that way at some point. > 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 :-/ Last summer (aka winter) is when we first discovered this issue with the long double size being implicated. See: https://git.kernel.org/torvalds/c/c653c591789b3acfa4bf6ae45d5af4f330e50a91 So I guess that's what prompted your patch? > 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@xxxxxxxxxxxxxxxxxxx> Thanks. cheers
