Guenter Roeck <linux@xxxxxxxxxxxx> writes: > On 7/25/22 13:42, Segher Boessenkool wrote: >> On Mon, Jul 25, 2022 at 02:34:08PM -0500, Timothy Pearson wrote: >>>>> Further digging shows that the build failures only occur with compilers >>>>> that default to 64-bit long double. >>>> >>>> Where the heck do we have 'long double' things anywhere in the kernel? >>>> >>>> I tried to grep for it, and failed miserably. I found some constants >>>> that would qualify, but they were in the v4l colorspaces-details.rst >>>> doc file. >>>> >>>> Strange. >>> >>> We don't, at least not that I can see. The affected code uses standard doubles. >>> >>> What I'm wondering is if the compiler is getting confused between standard and long doubles when they are both the same bit length... >> >> The compiler emits the same code (DFmode things, double precision float) >> in both cases, and it itself does not see any difference anymore fairly >> early in the pipeline. Compare to int and long on most 32-bit targets, >> both are SImode, the compiler will not see different types anymore: >> there *are* no types, except in the compiler frontend. >> >> It only happens for powerpc64le things, and not for powerpc64 builds. >> >> It is probably a GCC problem. I don't see what forces the GCC build >> here to use 64-bit long double either btw? Compilers build via buildall >> have all kinds of unnecessary things disabled, but not that, not >> directly at least. >> > > From what little documentation I can find, there appears to be > "--with-long-double-128" and "--with-long-double-format=ieee". > That looks like something that would need to be enabled, not disabled. > > FWIW, depending on compiler build options such as the above for kernel > builds seems to be a little odd to me, and I am not sure I'd want to > blame gcc if the kernel wants to be built with 128-bit floating point > as default. The kernel doesn't care what the size is, but ld refuses to link objects built with soft/hard float if the long double size is 64-bits. > At the very least, that should be documented somewhere, > and if possible the kernel should refuse to build if the compiler build > options don't meet the requirements. The ABI says long double is 128-bits. So it's documented there :) The kernel expects that passing `-m64 -mlittle-endian -mabi=elfv2` will produce code that conforms to the 64-bit Little Endian ELFv2 ABI :D But it seems those flags are not sufficient. There is an -mlong-double-128 flag, which appears to do the right thing regardless of how the compiler was built. I will probably add that to the kernel CFLAGS, but that's not a change I want to do just before the v5.19 release. cheers
