The complaint is:

In file included from ././include/xen/config.h:17,
                 from <command-line>:
arch/x86/smpboot.c: In function ‘link_thread_siblings.constprop’:
./include/asm-generic/percpu.h:16:51: error: array subscript [0, 0] is outside array bounds of ‘long unsigned int[1]’ [-Werror=array-bounds=]
   16 |     (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
./include/xen/compiler.h:140:29: note: in definition of macro ‘RELOC_HIDE’
  140 |     (typeof(ptr)) (__ptr + (off)); })
      |                             ^~~
arch/x86/smpboot.c:238:27: note: in expansion of macro ‘per_cpu’
  238 |     cpumask_set_cpu(cpu2, per_cpu(cpu_sibling_mask, cpu1));
      |                           ^~~~~~~
In file included from ./arch/x86/include/generated/asm/percpu.h:1,
                 from ./include/xen/percpu.h:30,
                 from ./arch/x86/include/asm/cpuid.h:9,
                 from ./arch/x86/include/asm/cpufeature.h:11,
                 from ./arch/x86/include/asm/system.h:6,
                 from ./include/xen/list.h:11,
                 from ./include/xen/mm.h:68,
                 from arch/x86/smpboot.c:12:
./include/asm-generic/percpu.h:12:22: note: while referencing ‘__per_cpu_offset’
   12 | extern unsigned long __per_cpu_offset[NR_CPUS];
      |                      ^~~~~~~~~~~~~~~~

Which I consider bogus in the first place ("array subscript [0, 0]" vs a
1-element array). Yet taking the experience from 99f942f3d410 ("Arm64:
adjust __irq_to_desc() to fix build with gcc14") I guessed that
switching function parameters to unsigned int (which they should have
been anyway) might help. And voilà ...

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -226,7 +226,7 @@ static int booting_cpu;
 /* CPUs for which sibling maps can be computed. */
 static cpumask_t cpu_sibling_setup_map;
 
-static void link_thread_siblings(int cpu1, int cpu2)
+static void link_thread_siblings(unsigned int cpu1, unsigned int cpu2)
 {
     cpumask_set_cpu(cpu1, per_cpu(cpu_sibling_mask, cpu2));
     cpumask_set_cpu(cpu2, per_cpu(cpu_sibling_mask, cpu1));

On 04/09/2024 11:15 am, Jan Beulich wrote:
> The complaint is:
>
> In file included from ././include/xen/config.h:17,
>                  from <command-line>:
> arch/x86/smpboot.c: In function ‘link_thread_siblings.constprop’:
> ./include/asm-generic/percpu.h:16:51: error: array subscript [0, 0] is outside array bounds of ‘long unsigned int[1]’ [-Werror=array-bounds=]
>    16 |     (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
> ./include/xen/compiler.h:140:29: note: in definition of macro ‘RELOC_HIDE’
>   140 |     (typeof(ptr)) (__ptr + (off)); })
>       |                             ^~~
> arch/x86/smpboot.c:238:27: note: in expansion of macro ‘per_cpu’
>   238 |     cpumask_set_cpu(cpu2, per_cpu(cpu_sibling_mask, cpu1));
>       |                           ^~~~~~~
> In file included from ./arch/x86/include/generated/asm/percpu.h:1,
>                  from ./include/xen/percpu.h:30,
>                  from ./arch/x86/include/asm/cpuid.h:9,
>                  from ./arch/x86/include/asm/cpufeature.h:11,
>                  from ./arch/x86/include/asm/system.h:6,
>                  from ./include/xen/list.h:11,
>                  from ./include/xen/mm.h:68,
>                  from arch/x86/smpboot.c:12:
> ./include/asm-generic/percpu.h:12:22: note: while referencing ‘__per_cpu_offset’
>    12 | extern unsigned long __per_cpu_offset[NR_CPUS];
>       |                      ^~~~~~~~~~~~~~~~
>
> Which I consider bogus in the first place ("array subscript [0, 0]" vs a
> 1-element array). Yet taking the experience from 99f942f3d410 ("Arm64:
> adjust __irq_to_desc() to fix build with gcc14") I guessed that
> switching function parameters to unsigned int (which they should have
> been anyway) might help. And voilà ...
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Presumably we're going to pick this up very very rarely on RANDCONFIG
now that someone regenerated the Tumbleweed containers ?

On 04.09.2024 12:24, Andrew Cooper wrote:
> On 04/09/2024 11:15 am, Jan Beulich wrote:
>> The complaint is:
>>
>> In file included from ././include/xen/config.h:17,
>>                  from <command-line>:
>> arch/x86/smpboot.c: In function ‘link_thread_siblings.constprop’:
>> ./include/asm-generic/percpu.h:16:51: error: array subscript [0, 0] is outside array bounds of ‘long unsigned int[1]’ [-Werror=array-bounds=]
>>    16 |     (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
>> ./include/xen/compiler.h:140:29: note: in definition of macro ‘RELOC_HIDE’
>>   140 |     (typeof(ptr)) (__ptr + (off)); })
>>       |                             ^~~
>> arch/x86/smpboot.c:238:27: note: in expansion of macro ‘per_cpu’
>>   238 |     cpumask_set_cpu(cpu2, per_cpu(cpu_sibling_mask, cpu1));
>>       |                           ^~~~~~~
>> In file included from ./arch/x86/include/generated/asm/percpu.h:1,
>>                  from ./include/xen/percpu.h:30,
>>                  from ./arch/x86/include/asm/cpuid.h:9,
>>                  from ./arch/x86/include/asm/cpufeature.h:11,
>>                  from ./arch/x86/include/asm/system.h:6,
>>                  from ./include/xen/list.h:11,
>>                  from ./include/xen/mm.h:68,
>>                  from arch/x86/smpboot.c:12:
>> ./include/asm-generic/percpu.h:12:22: note: while referencing ‘__per_cpu_offset’
>>    12 | extern unsigned long __per_cpu_offset[NR_CPUS];
>>       |                      ^~~~~~~~~~~~~~~~
>>
>> Which I consider bogus in the first place ("array subscript [0, 0]" vs a
>> 1-element array). Yet taking the experience from 99f942f3d410 ("Arm64:
>> adjust __irq_to_desc() to fix build with gcc14") I guessed that
>> switching function parameters to unsigned int (which they should have
>> been anyway) might help. And voilà ...
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks.

> Presumably we're going to pick this up very very rarely on RANDCONFIG
> now that someone regenerated the Tumbleweed containers ?

I expect so, yes.

Jan