Message ID | 20250124162248.60104eec848619a187242392@linux-foundation.org (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL] MM updates for 6.14-rc1 | expand |
On Fri, 24 Jan 2025 at 16:22, Andrew Morton <akpm@linux-foundation.org> wrote: > > Linus, please merge the MM updates for the 6.14 development cycle, This does not build at all for me. I get ./arch/x86/include/asm/current.h:49:9: error: call to undeclared function '__typeof_unqual__'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] when running the Rust 'bindgen', and what seems to be going on is that my version of *gcc* does support __typeof_unqual__, so I end up with CONFIG_CC_HAS_TYPEOF_UNQUAL=y in my kernel config, but I think that 'bindgen' that generates the Rust bindings is based on LLVM, and clearly does not understand __typeof_unqual__. I have bindgen 0.69.5 (plain F40 install), in case somebody wants to test. Apparently few people test linux-next with Rust enabled, and the reports that I find on lkml were ignored. I do see reports of this failure on lkml from mid-December, so it's not like I'm the first person ever to see this. Anyway, pulled and then unpulled again. Linus
On Sat, 25 Jan 2025 14:09:16 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Fri, 24 Jan 2025 at 16:22, Andrew Morton <akpm@linux-foundation.org> wrote: > > > > Linus, please merge the MM updates for the 6.14 development cycle, > > This does not build at all for me. > > I get > > ./arch/x86/include/asm/current.h:49:9: error: call to undeclared > function '__typeof_unqual__'; ISO C99 and later do not support > implicit function declarations [-Wimplicit-function-declaration] > > when running the Rust 'bindgen', and what seems to be going on is that > my version of *gcc* does support __typeof_unqual__, so I end up with > > CONFIG_CC_HAS_TYPEOF_UNQUAL=y > > in my kernel config, but I think that 'bindgen' that generates the > Rust bindings is based on LLVM, and clearly does not understand > __typeof_unqual__. > > I have bindgen 0.69.5 (plain F40 install), in case somebody wants to test. > > Apparently few people test linux-next with Rust enabled, and the > reports that I find on lkml were ignored. > > I do see reports of this failure on lkml from mid-December, so it's > not like I'm the first person ever to see this. > Well dang, nobody told me, and I assume Stephen didn't find out. Guys, if tree owners are carrying bad patches, please do give them a heads-up! > Anyway, pulled and then unpulled again. OK, I've dropped Uroz's series "Enable strict percpu address space checks", shall resend the pull request soon. And I shall continue to scratch my head over Documentation/rust/quick-start.rst.
On Sat, 25 Jan 2025 at 21:00, Andrew Morton <akpm@linux-foundation.org> wrote: > > And I shall continue to scratch my head over > Documentation/rust/quick-start.rst. It really should be as simple as installing the proper distro packages, and then "make allmodconfig" will enable Rust. It used to be much more complicated. So do the pacman / apt / dnf / emerge / zypper command line to just install the packages, and off you go. Of course, that assumes you have a modern enough distro that it _has_ sufficiently up-to-date rust packages. So if you are on something like Debian stable, it's simply not worth the pain. Linus
Hi all, On Sat, 25 Jan 2025 21:00:16 -0800 Andrew Morton <akpm@linux-foundation.org> wrote: > > On Sat, 25 Jan 2025 14:09:16 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > On Fri, 24 Jan 2025 at 16:22, Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > Linus, please merge the MM updates for the 6.14 development cycle, > > > > This does not build at all for me. > > > > I get > > > > ./arch/x86/include/asm/current.h:49:9: error: call to undeclared > > function '__typeof_unqual__'; ISO C99 and later do not support > > implicit function declarations [-Wimplicit-function-declaration] > > > > when running the Rust 'bindgen', and what seems to be going on is that > > my version of *gcc* does support __typeof_unqual__, so I end up with > > > > CONFIG_CC_HAS_TYPEOF_UNQUAL=y > > > > in my kernel config, but I think that 'bindgen' that generates the > > Rust bindings is based on LLVM, and clearly does not understand > > __typeof_unqual__. > > > > I have bindgen 0.69.5 (plain F40 install), in case somebody wants to test. > > > > Apparently few people test linux-next with Rust enabled, and the > > reports that I find on lkml were ignored. I don't recall seeing them ... were they cc'd to linux-next@vger or me? > > I do see reports of this failure on lkml from mid-December, so it's > > not like I'm the first person ever to see this. > > Well dang, nobody told me, and I assume Stephen didn't find out. I did not get any errors in my builds. I am running Debian Testing on a PowerPC LE machine (so my x86_64 allmodconfig builds are cross builds). $ gcc --version gcc (Debian 14.2.0-12) 14.2.0 $ bindgen --version bindgen 0.70.1 ~/next/x86_64_allmodconfig$ grep -E '(CONFIG_CC_HAS_TYPEOF_UNQUAL|_RUST)' .config CONFIG_RUSTC_VERSION=108300 CONFIG_RUST_IS_AVAILABLE=y CONFIG_RUSTC_LLVM_VERSION=190104 CONFIG_CC_HAS_TYPEOF_UNQUAL=y CONFIG_RUST=y CONFIG_RUSTC_VERSION_TEXT="rustc 1.83.0 (90b35a623 2024-11-26) (built from a source tarball)" CONFIG_HAVE_RUST=y CONFIG_RUST_FW_LOADER_ABSTRACTIONS=y CONFIG_BLK_DEV_RUST_NULL=m CONFIG_SAMPLES_RUST=y CONFIG_SAMPLE_RUST_MINIMAL=m CONFIG_SAMPLE_RUST_MISC_DEVICE=m CONFIG_SAMPLE_RUST_PRINT=m CONFIG_SAMPLE_RUST_DRIVER_PCI=m CONFIG_SAMPLE_RUST_DRIVER_PLATFORM=m CONFIG_SAMPLE_RUST_HOSTPROGS=y CONFIG_RUST_DEBUG_ASSERTIONS=y CONFIG_RUST_OVERFLOW_CHECKS=y CONFIG_RUST_BUILD_ASSERT_ALLOW=y
On Sat, Jan 25, 2025 at 11:09 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Fri, 24 Jan 2025 at 16:22, Andrew Morton <akpm@linux-foundation.org> wrote: > > > > Linus, please merge the MM updates for the 6.14 development cycle, > > This does not build at all for me. > > I get > > ./arch/x86/include/asm/current.h:49:9: error: call to undeclared > function '__typeof_unqual__'; ISO C99 and later do not support > implicit function declarations [-Wimplicit-function-declaration] > > when running the Rust 'bindgen', and what seems to be going on is that > my version of *gcc* does support __typeof_unqual__, so I end up with > > CONFIG_CC_HAS_TYPEOF_UNQUAL=y > > in my kernel config, but I think that 'bindgen' that generates the > Rust bindings is based on LLVM, and clearly does not understand __typeof_unqual__ is available in Clang 19.1.0 in all C modes as an extension [1] and as reported in [2], bindgen 0,70.1 seems to parse __typeof_unqual__ okay. [1] https://releases.llvm.org/19.1.0/tools/clang/docs/ReleaseNotes.html [2] https://lore.kernel.org/lkml/9fa81826-8fa6-47e4-a0a2-4916e5d042a7@stanley.mountain/ Maybe configure could detect bindgen version and disable CC_HAS_TYPEOF_UNQUAL [3] if it is too old? [3] https://lore.kernel.org/lkml/20241208204708.3742696-3-ubizjak@gmail.com/ Uros.
On Sun, Jan 26, 2025 at 6:00 AM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Sat, 25 Jan 2025 14:09:16 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > On Fri, 24 Jan 2025 at 16:22, Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > Linus, please merge the MM updates for the 6.14 development cycle, > > > > This does not build at all for me. > > > > I get > > > > ./arch/x86/include/asm/current.h:49:9: error: call to undeclared > > function '__typeof_unqual__'; ISO C99 and later do not support > > implicit function declarations [-Wimplicit-function-declaration] > > > > when running the Rust 'bindgen', and what seems to be going on is that > > my version of *gcc* does support __typeof_unqual__, so I end up with > > > > CONFIG_CC_HAS_TYPEOF_UNQUAL=y > > > > in my kernel config, but I think that 'bindgen' that generates the > > Rust bindings is based on LLVM, and clearly does not understand > > __typeof_unqual__. > > > > I have bindgen 0.69.5 (plain F40 install), in case somebody wants to test. > > > > Apparently few people test linux-next with Rust enabled, and the > > reports that I find on lkml were ignored. > > > > I do see reports of this failure on lkml from mid-December, so it's > > not like I'm the first person ever to see this. > > > > Well dang, nobody told me, and I assume Stephen didn't find out. > > Guys, if tree owners are carrying bad patches, please do give them a > heads-up! > > > Anyway, pulled and then unpulled again. > > OK, I've dropped Uroz's series "Enable strict percpu address space > checks", shall resend the pull request soon. Patch 1/6 "x86/kgdb: Use IS_ERR_PCPU() macro" is required for the rest of the series, but can be committed as an independent improvement.. Uros.
On Sun, Jan 26, 2025 at 10:57 AM Uros Bizjak <ubizjak@gmail.com> wrote: > > On Sat, Jan 25, 2025 at 11:09 PM Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > On Fri, 24 Jan 2025 at 16:22, Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > Linus, please merge the MM updates for the 6.14 development cycle, > > > > This does not build at all for me. > > > > I get > > > > ./arch/x86/include/asm/current.h:49:9: error: call to undeclared > > function '__typeof_unqual__'; ISO C99 and later do not support > > implicit function declarations [-Wimplicit-function-declaration] > > > > when running the Rust 'bindgen', and what seems to be going on is that > > my version of *gcc* does support __typeof_unqual__, so I end up with > > > > CONFIG_CC_HAS_TYPEOF_UNQUAL=y > > > > in my kernel config, but I think that 'bindgen' that generates the > > Rust bindings is based on LLVM, and clearly does not understand > > __typeof_unqual__ is available in Clang 19.1.0 in all C modes as an > extension [1] and as reported in [2], bindgen 0,70.1 seems to parse > __typeof_unqual__ okay. > > [1] https://releases.llvm.org/19.1.0/tools/clang/docs/ReleaseNotes.html > [2] https://lore.kernel.org/lkml/9fa81826-8fa6-47e4-a0a2-4916e5d042a7@stanley.mountain/ > > Maybe configure could detect bindgen version and disable > CC_HAS_TYPEOF_UNQUAL [3] if it is too old? bindgen ChangeLog does not mention __typeof_unqual__, so I assume that the support depends on RUSTC_LLVM_VERSION. Does the attached incremental patch work for you? Uros. diff --git a/init/Kconfig b/init/Kconfig index a1507b8714e4..d342371dd15d 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -898,7 +898,9 @@ config CC_HAS_INT128 def_bool !$(cc-option,$(m64-flag) -D__SIZEOF_INT128__=0) && 64BIT config CC_HAS_TYPEOF_UNQUAL - def_bool $(success,echo 'int foo (int a) { __typeof_unqual__(a) b = a; return b; }' | $(CC) -x c - -S -o /dev/null) + def_bool y + depends on $(success,echo 'int foo (int a) { __typeof_unqual__(a) b = a; return b; }' | $(CC) -x c - -S -o /dev/null) + depends on !RUST || RUSTC_LLVM_VERSION >= 190000 config CC_IMPLICIT_FALLTHROUGH string
On Sun, 26 Jan 2025 at 09:22, Uros Bizjak <ubizjak@gmail.com> wrote: > > bindgen ChangeLog does not mention __typeof_unqual__, so I assume that > the support depends on RUSTC_LLVM_VERSION. That seems to be a reasonable assumption. I guess some crazy setup *could* install a bindgen that uses a different llvm version than rustc itself, but that sounds pretty damn broken. Let's add Miguel to the participants. Miguel, see https://lore.kernel.org/all/CAHk-=whddBhfi5DUi370W3pYs+z3r2E7KYuHjwR=a1eRig5Gxg@mail.gmail.com/ for my "this doesn't work" report, and then Uros' suggested fix in https://lore.kernel.org/all/CAFULd4a-2F_zKMeR0Yjo2WhRLmyoOQ1VdR2qdV34BrM-b_cQCQ@mail.gmail.com/ > Does the attached incremental patch work for you? That does seem to work, but I'd admittedly be happier if we could just find some way to dynamically disable/enable __typeof_unqual__ based on which compiler is used, rather than make it a config option. So that bindgen would not see it, but a recent enough C compiler would. We already use '__has_attribute()' for some of these things. There's a '__has_extension()' thing that comes from clang but that gcc also supports. But I can't find the list of extensions that that model supports, and I guess typeof_unqual isn't on that list if I find it. In the absence of something _clean_ like that, can we just do it in <linux/compiler-xyz.h> instead? IOW, not use the CONFIG_xyz tests for this at all, but do something like /* * bindgen uses LLVM even if our C compiler is gcc, so we cannot * rely on CONFIG_CC_HAS_TYPEOF_UNQUAL */ #if __clang_major__ >= 19 # define CC_HAS_TYPEOF_UNQUAL 1 #endif in <linux/compiler-clang.h> and the gcc version check for gcc (I don't know when __typeof_unqual__ made it)? This does show that our whole "CC_HAS_XYZ" is kind of broken for the Rust integration in general. Linus
On Sun, Jan 26, 2025 at 7:30 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > That does seem to work, but I'd admittedly be happier if we could just > find some way to dynamically disable/enable __typeof_unqual__ based on > which compiler is used, rather than make it a config option. So that > bindgen would not see it, but a recent enough C compiler would. > > We already use '__has_attribute()' for some of these things. There's a > '__has_extension()' thing that comes from clang but that gcc also > supports. > > But I can't find the list of extensions that that model supports, and > I guess typeof_unqual isn't on that list if I find it. > > In the absence of something _clean_ like that, can we just do it in > <linux/compiler-xyz.h> instead? IOW, not use the CONFIG_xyz tests for > this at all, but do something like > > /* > * bindgen uses LLVM even if our C compiler is gcc, so we cannot > * rely on CONFIG_CC_HAS_TYPEOF_UNQUAL > */ > #if __clang_major__ >= 19 > # define CC_HAS_TYPEOF_UNQUAL 1 > #endif > > in <linux/compiler-clang.h> and the gcc version check for gcc (I don't > know when __typeof_unqual__ made it)? It is available in gcc-14. Uros.
On Sun, Jan 26, 2025 at 8:46 PM Uros Bizjak <ubizjak@gmail.com> wrote: > > On Sun, Jan 26, 2025 at 7:30 PM Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > That does seem to work, but I'd admittedly be happier if we could just > > find some way to dynamically disable/enable __typeof_unqual__ based on > > which compiler is used, rather than make it a config option. So that > > bindgen would not see it, but a recent enough C compiler would. > > > > We already use '__has_attribute()' for some of these things. There's a > > '__has_extension()' thing that comes from clang but that gcc also > > supports. > > > > But I can't find the list of extensions that that model supports, and > > I guess typeof_unqual isn't on that list if I find it. Sorry, I sent the previous message too fast. Unfortunately, you are right. The following doesn't trigger #error neither with gcc, neither with clang: #if __has_extension (__typeof_unqual__) # error #endif Uros.
On Sun, Jan 26, 2025 at 7:30 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > Let's add Miguel to the participants. Miguel, see > > https://lore.kernel.org/all/CAHk-=whddBhfi5DUi370W3pYs+z3r2E7KYuHjwR=a1eRig5Gxg@mail.gmail.com/ Thanks for the Cc -- I build linux-next with Rust enabled with some configs/compilers/arches variations, and I also have a run using Fedora's latest container image for rust-next, but not the combination of both (and I mostly do Clang builds). I will add a couple distro builds for linux-next in my matrix, one including GCC, so that hopefully at least you don't get blocked with something like this. > for my "this doesn't work" report, and then Uros' suggested fix in > > https://lore.kernel.org/all/CAFULd4a-2F_zKMeR0Yjo2WhRLmyoOQ1VdR2qdV34BrM-b_cQCQ@mail.gmail.com/ RUSTC_LLVM_VERSION is indeed not necessarily bindgen's libclang. One can see the latter's version with: bindgen --version --verbose Though in `scripts/rust_is_available.sh` we use this to support older ones: bindgen scripts/rust_is_available_bindgen_libclang.h 2>&1 | sed -nE 's:.*clang version ([0-9]+\.[0-9]+\.[0-9]+).*:\1:p' So we could easily add a `BINDGEN_LLVM_VERSION` if we go that route. (We also fetch bindgen's Clang version in `rust/Makefile` already to tweak a flag, so this could be useful anyway.) We could also do a `BINDGEN_CLANG_HAS_TYPEOF_UNQUAL`, i.e. mimicking the `CC` one. A bigger hammer is using the `#define` we already pass when using `bindgen`, i.e. `!defined(__BINDGEN__)`, in the source code. I tried this one quickly and seems to work, but we would need it in both places `__CHECKER__` is. > That does seem to work, but I'd admittedly be happier if we could just > find some way to dynamically disable/enable __typeof_unqual__ based on > which compiler is used, rather than make it a config option. So that > bindgen would not see it, but a recent enough C compiler would. > > We already use '__has_attribute()' for some of these things. There's a > '__has_extension()' thing that comes from clang but that gcc also > supports. > > But I can't find the list of extensions that that model supports, and > I guess typeof_unqual isn't on that list if I find it. In LLVM it seems to be at `clang/include/clang/Basic/Features.def`, but from a quick look at that and the commits that added `typeof_unqual` I don't see it (but it seems it could have been there, indeed, given other keywords are listed there): https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/Features.def In GCC I see a few at `gcc/c-family/c-common.cc` (`has_feature_table`) and `gcc/c/c-objc-common.cc` (`c_feature_table`). I can't see `typeof_unqual`. > This does show that our whole "CC_HAS_XYZ" is kind of broken for the > Rust integration in general. Yes, bindgen being libclang-only is one of the main reasons why we call GCC builds with Rust enabled "very experimental" (and why Rust doesn't work with GCC's randstruct plugin and things like that). Ideally bindgen would have a way to parse code using GCC (https://github.com/rust-lang/rust-bindgen/issues/1949), or perhaps it could fetch layout information in a completely different way, e.g. building a C file that computes it. There have been some discussions and even some code written about this over the years, but so far nothing really usable yet. Cheers, Miguel
On Sun, Jan 26, 2025 at 7:30 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > That seems to be a reasonable assumption. I guess some crazy setup > *could* install a bindgen that uses a different llvm version than > rustc itself, but that sounds pretty damn broken. Tangential to the issue, but a note on this: we have a few warnings in that `rust_is_available.sh` script for things that "do not look great", such as bindgen's libclang != Clang when `CC` is Clang, and we could have a warning for the case you mention, i.e. bindgen's libclang != rustc's LLVM. However, currently some kernel developers use toolchains from upstream Rust (e.g. from `rustup`) instead of their distributions, so that could be annoying for them (since their bindgen may be picking libclang from their distribution). But eventually when things stabilize more it could make sense, if most developers stop using those, as a by-default warning. Cheers, Miguel
On Sun, Jan 26, 2025 at 09:28:09PM +0100, Miguel Ojeda wrote: > I will add a couple distro builds for linux-next in my matrix, one > including GCC, so that hopefully at least you don't get blocked with > something like this. FYI, this was picked up: https://lore.kernel.org/all/CA+G9fYuP2bHnDvJwfMm6+8Y8UYk74qCw-2HsFyRzJDFiQ5dbpQ@mail.gmail.com/ But, I guess due to the xmas break, nobody figured it out. It even went to the Rust list via Dan Carpenter's response.
On Sun, Jan 26, 2025 at 10:19 PM Matthew Wilcox <willy@infradead.org> wrote: > > FYI, this was picked up: > > https://lore.kernel.org/all/CA+G9fYuP2bHnDvJwfMm6+8Y8UYk74qCw-2HsFyRzJDFiQ5dbpQ@mail.gmail.com/ > > But, I guess due to the xmas break, nobody figured it out. It even > went to the Rust list via Dan Carpenter's response. I missed that, sorry. Cheers, Miguel
On Sun, 26 Jan 2025 at 11:47, Uros Bizjak <ubizjak@gmail.com> wrote: > > > #if __clang_major__ >= 19 > > # define CC_HAS_TYPEOF_UNQUAL 1 > > #endif > > It is available in gcc-14. Ok, let's take that approach, instead of messing with CONFIG_CC_HAS_xyz. Andrew - if you send me the MM pull without this series, I think we can sort this whole mess out later. We should probably look at a few other CONFIG_CC_HAS_xyz cases, but from a quick grep the existing cases seem fairly harmless and obviously haven't triggered these kinds of issues. Linus
On Sun, Jan 26, 2025 at 11:00 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Sun, 26 Jan 2025 at 11:47, Uros Bizjak <ubizjak@gmail.com> wrote: > > > > > #if __clang_major__ >= 19 > > > # define CC_HAS_TYPEOF_UNQUAL 1 > > > #endif > > > > It is available in gcc-14. > > Ok, let's take that approach, instead of messing with CONFIG_CC_HAS_xyz. Please find attached an incremental patch that implements the proposed approach. The detection is put in include/linux/compiler.h where we can consolidate checks for both compilers: --cut here-- /* * Declare compiler support for __typeof_unqual__() operator. * * bindgen uses LLVM even if our C compiler is gcc, so we cannot * rely on the auto-detected CONFIG_CC_HAS_TYPEOF_UNQUAL. * * XXX: Remove test for __CHECKER__ once * sparse learns about __typeof_unqual__. */ #if ((defined(__GNUC__) && __GNUC__ >= 14) || \ (defined(__clang__) && __clang_major__ >= 19)) && \ !defined(__CHECKER__) # define CC_HAS_TYPEOF_UNQUAL 1 #endif /* * Define TYPEOF_UNQUAL() to use __typeof_unqual__() as typeof * operator when available, to return an unqualified type of the exp. */ #if defined(CC_HAS_TYPEOF_UNQUAL) # define TYPEOF_UNQUAL(exp) __typeof_unqual__(exp) #else # define TYPEOF_UNQUAL(exp) __typeof__(exp) #endif --cut here-- The above also consolidates checks for __CHECKER__, resulting in a much simpler compile check in arch/x86/include/percpu.h. I have tested the new patch series with a bunch of compilers, works as expected, but it is getting a bit late here. I'll resend the series tomorrow, after some more testing. Uros. diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h index 1ef08289e667..9f0831a5e712 100644 --- a/arch/x86/include/asm/percpu.h +++ b/arch/x86/include/asm/percpu.h @@ -95,12 +95,7 @@ #endif /* CONFIG_SMP */ -/* - * XXX: Remove test for __CHECKER__ once - * sparse learns about __typeof_unqual__. - */ -#if defined(CONFIG_USE_X86_SEG_SUPPORT) && \ - defined(CONFIG_CC_HAS_TYPEOF_UNQUAL) && !defined(__CHECKER__) +#if defined(CONFIG_USE_X86_SEG_SUPPORT) && defined(CC_HAS_TYPEOF_UNQUAL) # define __my_cpu_type(var) typeof(var) # define __my_cpu_ptr(ptr) (ptr) # define __my_cpu_var(var) (var) diff --git a/include/linux/compiler.h b/include/linux/compiler.h index eac58025ecfc..7a52bea4ba76 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -314,13 +314,25 @@ static inline void *offset_to_ptr(const int *off) #define prevent_tail_call_optimization() mb() /* - * Define TYPEOF_UNQUAL() to use __typeof_unqual__() as typeof - * operator when available, to return unqualified type of the exp. + * Declare compiler support for __typeof_unqual__() operator. + * + * bindgen uses LLVM even if our C compiler is gcc, so we cannot + * rely on the auto-detected CONFIG_CC_HAS_TYPEOF_UNQUAL. * * XXX: Remove test for __CHECKER__ once * sparse learns about __typeof_unqual__. */ -#if defined(CONFIG_CC_HAS_TYPEOF_UNQUAL) && !defined(__CHECKER__) +#if ((defined(__GNUC__) && __GNUC__ >= 14) || \ + (defined(__clang__) && __clang_major__ >= 19)) && \ + !defined(__CHECKER__) +# define CC_HAS_TYPEOF_UNQUAL 1 +#endif + +/* + * Define TYPEOF_UNQUAL() to use __typeof_unqual__() as typeof + * operator when available, to return an unqualified type of the exp. + */ +#if defined(CC_HAS_TYPEOF_UNQUAL) # define TYPEOF_UNQUAL(exp) __typeof_unqual__(exp) #else # define TYPEOF_UNQUAL(exp) __typeof__(exp) diff --git a/init/Kconfig b/init/Kconfig index a1507b8714e4..7fe82a46e88c 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -897,9 +897,6 @@ config ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH config CC_HAS_INT128 def_bool !$(cc-option,$(m64-flag) -D__SIZEOF_INT128__=0) && 64BIT -config CC_HAS_TYPEOF_UNQUAL - def_bool $(success,echo 'int foo (int a) { __typeof_unqual__(a) b = a; return b; }' | $(CC) -x c - -S -o /dev/null) - config CC_IMPLICIT_FALLTHROUGH string default "-Wimplicit-fallthrough=5" if CC_IS_GCC && $(cc-option,-Wimplicit-fallthrough=5)
On Sun, 26 Jan 2025 at 15:27, Uros Bizjak <ubizjak@gmail.com> wrote: > > The detection is put in include/linux/compiler.h where we can > consolidate checks for both compilers: No. Please. We have compiler-specific header files for a reason. Exactly so that we do *not* need to have disgusting tests like #if ((defined(__GNUC__) && __GNUC__ >= 14) || \ (defined(__clang__) && __clang_major__ >= 19)) && \ !defined(__CHECKER__) and instead it should just be #define CC_HAS_TYPEOF_UNQUAL (__clang_major__ >= 19) in compiler-clang.h, and #define CC_HAS_TYPEOF_UNQUAL (__GNUC__ >= 14) in compiler-gcc.h. And then in the actual compiler.h, we could do #define USE_TYPEOF_UNQUAL (CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__)) and now the places that then want to use __typeof_unqual__ have a very straightforward way to check if they should do so. Linus