(cc Arnd) On Thu, 11 Apr 2024 at 03:11, Samuel Holland <samuel.holland@xxxxxxxxxx> wrote: > > Hi Thiago, > > On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote: > > Samuel Holland <samuel.holland@xxxxxxxxxx> writes: > >> On 2024-04-10 5:21 PM, Thiago Jung Bauermann wrote: > >>> > >>> Unfortunately this patch causes build failures on arm with allyesconfig > >>> and allmodconfig. Tested with next-20240410. > > > > <snip> > > > >> In both cases, the issue is that the toolchain requires runtime support to > >> convert between `unsigned long long` and `double`, even when hardware FP is > >> enabled. There was some past discussion about GCC inlining some of these > >> conversions[1], but that did not get implemented. > > > > Thank you for the explanation and the bugzilla reference. I added a > > comment there mentioning that the problem came up again with this patch > > series. > > > >> The short-term fix would be to drop the `select ARCH_HAS_KERNEL_FPU_SUPPORT` for > >> 32-bit arm until we can provide these runtime library functions. > > > > Does this mean that patch 2 in this series: > > > > [PATCH v4 02/15] ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT > > > > will be dropped? > > No, because later patches in the series (3, 6) depend on the definition of > CC_FLAGS_FPU from that patch. I will need to send a fixup patch unless I can > find a GPL-2 compatible implementation of the runtime library functions. > Is there really a point to doing that? Do 32-bit ARM systems even have enough address space to the map the BARs of the AMD GPUs that need this support? Given that this was not enabled before, I don't think the upshot of this series should be that we enable support for something on 32-bit ARM that may cause headaches down the road without any benefit. So I'd prefer a fixup patch that opts ARM out of this over adding support code for 64-bit conversions.
