On Wed, Mar 19, 2025 at 9:06 AM Uros Bizjak <ubizjak@xxxxxxxxx> wrote: > > On Wed, Mar 19, 2025 at 3:55 PM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi > > <memxor@xxxxxxxxx> wrote: > > > > > > > > > > > > > I've sent a fix [0], but unfortunately I was unable to reproduce the > > > > > problem with an LLVM >= 19 build, idk why. I will try with GCC >= 14 > > > > > as the patches require to confirm, but based on the error I am 99% > > > > > sure it will fix the problem. > > > > > > > > Probably because __seg_gs has CC_HAS_NAMED_AS depends on CC_IS_GCC. > > > > Let me give it a go with GCC. > > > > > > > > > > Can confirm now that this fixes it, I just did a build with GCC 14 > > > where Uros's __percpu checks kick in. > > > > Great. Thanks for checking and quick fix. > > > > btw clang supports it with __attribute__((address_space(256))), > > so CC_IS_GCC probably should be relaxed. > > https://github.com/llvm/llvm-project/issues/93449 > > needs to be fixed first. Also, the feature has to be thoroughly tested > (preferably by someone having a deep knowledge of clang) before it is > enabled by default. clang error makes sense to me. What does it even mean to do addr space cast from percpu to normal address: __typeof__(int __seg_gs) const_pcpu_hot; void *__attribute____UNIQUE_ID___addressable_const_pcpu_hot612 = (void *)(long)&const_pcpu_hot; I'm curious what kind of code gcc generates. In bpf backend we have the concept of address spaces and there are explicit instructions generated to convert from one addr space to another.
