On 4/17/25 5:04 PM, Bart Van Assche wrote: > On 4/16/25 2:44 AM, Chen Linxuan via B4 Relay wrote: > > 2. Make it depends on X86 and LOONGARCH, > > as I haven't test other architectures > > That sounds weird to me. Shouldn't this option be made architecture- > independent? It should, but I have only tested it on X86 and LOONGARCH. > > > +config NO_AUTO_INLINE > > + bool "Disable compiler auto-inline optimizations (EXPERIMENTAL)" > > + default n > > + depends on CC_IS_GCC && (X86 || LOONGARCH) > > Why "depends on CC_IS_GCC"? Please make sure that both gcc and clang are > supported. I make it depends on CC_IS_GCC because 1. Clang do not have `-fno-inline-small-functions` and `-fno-inline-functions-called-once`. 2. If we wrap those options with cc-option, Clang 18.1.3 fails to compile test_bitmap_const_eval(), with config KASAN and TEST_BITMAP is enabled. Comments above test_bitmap_const_eval() says that: > /* > * FIXME: Clang breaks compile-time evaluations when KASAN and GCOV are enabled. > * To workaround it, GCOV is force-disabled in Makefile for this configuration. > */ It seems there are some issues with Clang's compile-time evaluations. So I think there are some ways to workaround this problem: 1. Make NO_AUTO_INLINE depends on CC_IS_GCC; 2. Make NO_AUTO_INLINE depends on KASAN=n; 3. Disable NO_AUTO_INLINE for TEST_BITMAP like how we handle CC_IS_CLANG && KASAN && GCOV in lib/Makefile: > ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_KASAN),yy) > # FIXME: Clang breaks test_bitmap_const_eval when KASAN and GCOV are enabled > GCOV_PROFILE_test_bitmap.o := n > endif Which one do you prefer or do you have any other suggestions? > > Thanks, > > Bart.
