From: Kameron Carr <[email protected]> Sent: Wednesday, August 5, 2026 10:16 AM
[snip] > > > > > > > > > > Using min() compiled fine on ARM, but x86 is throwing a compile error. > > > > > > > > > > drivers/hv/channel.c: In function 'vmbus_alloc_buffer': > > > > > ././include/linux/compiler_types.h:699:45: error: call to > > > > > '__compiletime_assert_518' declared with attribute error: > > > > > min(order, ( > > > > > __builtin_constant_p(remaining) ? ((remaining) < 2 ? 0 : 63 - > > > > > __builtin_clzll(remaining)) : (sizeof(remaining) <= 4) ? > > > > > __ilog2_u32(remaining) : __ilog2_u64(remaining) )) signedness > > > > > error > > > > > > > > > > In my v3 I may go back to using min_t. Please let me know if a cast > > > > > (or > > > > > some other method) is preferred. > > > > > > > > Hmmm. I don't get the same compile error on x86/x64. Maybe it is > > > > related to compiler and version, or the kernel code base against which > > > > the patch is being built. Probably you didn't see a problem on arm64 > > > > because of some such difference. FWIW, I built with gcc 11.4.0 against > > > > linux-next20260726. What is the compiler and base kernel info where > > > > you saw the error and on arm64 where you didn't? > > > > > > In both cases, I built against hyperv-next (a4ffc59). > > > On ARM64 I used gcc 13.2.0; on x86 I used 13.3.0. > > > > > > To do a fair comparison, I > > > * downgraded my x86 environment to gcc 13.2.0 > > > * started with `make defconfig` > > > * enabled Hyper-V and NetVSC in the config (=y) > > > > > > I saw the same behavior where there was no error on ARM and compile > > > failure > > > on x86. > > > > > > > Really weird. I compiled on x86/x64 with gcc 13.3.0, and saw no > > problem. This was against the official 7.1.0 release source code. > > Then I grabbed hyperv-next (the tag "hyperv-next-signed-20260621" > > specifically), added your patches, and again using gcc 13.3.0 I > > built with no problem. Are you using the same local copy of the > > source code for arm64 and x86/x64 builds? If not, I wonder if > > your local x86/x64 source code tree is somehow corrupt or not > > what you think it is. > > > > My .config file is different from yours. I did not try starting fresh > > with make defconfig and then enable Hyper-V and netvsc. > > Automated testing is picking up the same compiler error > https://lore.kernel.org/all/[email protected]/ > > tree: net-next > arch: amd64 > compiler: Debian clang version 22.1.8 > > This points to a real issue, not a corruption issue. > > I believe the right course is to explicitly do an unsigned comparison > instead of relying on the compiler to allow a comparison between a > signed and unsigned value. > Agreed. I don't have any ideas at the moment on how to further investigate why it's OK sometimes and other times not. Michael
