Hi Alexander,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: fdf0eaf11452d72945af31804e2a1048ee1b574c
commit: dc34d5036692c614eef23c1130ee42a201c316bf lib: test_bitmap: add compile-time optimization/evaluations assertions
date: 1 year, 1 month ago
config: arm64-randconfig-r031-20230717 (https://download.01.org/0day-ci/archive/20230717/[email protected]/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project.git f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce: (https://download.01.org/0day-ci/archive/20230717/[email protected]/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
All errors (new ones prefixed by >>):
>> lib/test_bitmap.c:920:2: error: call to __compiletime_assert_348 declared with 'error' attribute: BUILD_BUG_ON failed: !__builtin_constant_p(res)
BUILD_BUG_ON(!__builtin_constant_p(res));
^
include/linux/build_bug.h:50:2: note: expanded from macro 'BUILD_BUG_ON'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^
include/linux/build_bug.h:39:37: note: expanded from macro 'BUILD_BUG_ON_MSG'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^
include/linux/compiler_types.h:352:2: note: expanded from macro 'compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^
include/linux/compiler_types.h:340:2: note: expanded from macro '_compiletime_assert'
__compiletime_assert(condition, msg, prefix, suffix)
^
include/linux/compiler_types.h:333:4: note: expanded from macro '__compiletime_assert'
prefix ## suffix(); \
^
<scratch space>:287:1: note: expanded from here
__compiletime_assert_348
^
1 error generated.
vim +/error +920 lib/test_bitmap.c
871
872 static void __init test_bitmap_const_eval(void)
873 {
874 DECLARE_BITMAP(bitmap, BITS_PER_LONG);
875 unsigned long initvar = BIT(2);
876 unsigned long bitopvar = 0;
877 unsigned long var = 0;
878 int res;
879
880 /*
881 * Compilers must be able to optimize all of those to compile-time
882 * constants on any supported optimization level (-O2, -Os) and any
883 * architecture. Otherwise, trigger a build bug.
884 * The whole function gets optimized out then, there's nothing to do
885 * in runtime.
886 */
887
888 /*
889 * Equals to `unsigned long bitmap[1] = { GENMASK(6, 5), }`.
890 * Clang on s390 optimizes bitops at compile-time as intended, but at
891 * the same time stops treating @bitmap and @bitopvar as compile-time
892 * constants after regular test_bit() is executed, thus triggering the
893 * build bugs below. So, call const_test_bit() there directly until
894 * the compiler is fixed.
895 */
896 bitmap_clear(bitmap, 0, BITS_PER_LONG);
897 #if defined(__s390__) && defined(__clang__)
898 if (!const_test_bit(7, bitmap))
899 #else
900 if (!test_bit(7, bitmap))
901 #endif
902 bitmap_set(bitmap, 5, 2);
903
904 /* Equals to `unsigned long bitopvar = BIT(20)` */
905 __change_bit(31, &bitopvar);
906 bitmap_shift_right(&bitopvar, &bitopvar, 11, BITS_PER_LONG);
907
908 /* Equals to `unsigned long var = BIT(25)` */
909 var |= BIT(25);
910 if (var & BIT(0))
911 var ^= GENMASK(9, 6);
912
913 /* __const_hweight<32|64>(GENMASK(6, 5)) == 2 */
914 res = bitmap_weight(bitmap, 20);
915 BUILD_BUG_ON(!__builtin_constant_p(res));
916 BUILD_BUG_ON(res != 2);
917
918 /* !(BIT(31) & BIT(18)) == 1 */
919 res = !test_bit(18, &bitopvar);
> 920 BUILD_BUG_ON(!__builtin_constant_p(res));
921 BUILD_BUG_ON(!res);
922
923 /* BIT(2) & GENMASK(14, 8) == 0 */
924 res = initvar & GENMASK(14, 8);
925 BUILD_BUG_ON(!__builtin_constant_p(res));
926 BUILD_BUG_ON(res);
927
928 /* ~BIT(25) */
929 BUILD_BUG_ON(!__builtin_constant_p(~var));
930 BUILD_BUG_ON(~var != ~BIT(25));
931 }
932
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Mon, Jul 17, 2023 at 12:42:57PM +0800, kernel test robot wrote:
> Hi Alexander,
>
> FYI, the error/warning still remains.
Alexander, either you can escalate this or just propose something to discuss.
--
With Best Regards,
Andy Shevchenko
On Mon, Jul 17, 2023 at 3:04 AM Andy Shevchenko
<[email protected]> wrote:
>
> On Mon, Jul 17, 2023 at 12:42:57PM +0800, kernel test robot wrote:
> > Hi Alexander,
> >
> > FYI, the error/warning still remains.
>
> Alexander, either you can escalate this or just propose something to discuss.
https://github.com/ClangBuiltLinux/linux/issues/1874
Sorry, a few more fires have popped up in the meantime. Regardless of
changes to the compiler, we still support many versions of clang for
the kernel, so we'd need some workaround in the tests regardless. I
saw there was already one for s390 + clang, but from this report we
will need another. Feel free to use that link above in comments in the
tests; we will clean those up once I have a better grasp on what's
going on with the compiler here.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
>
--
Thanks,
~Nick Desaulniers
On Mon, Jul 17, 2023 at 09:35:49AM -0700, Nick Desaulniers wrote:
> On Mon, Jul 17, 2023 at 3:04 AM Andy Shevchenko
> <[email protected]> wrote:
> >
> > On Mon, Jul 17, 2023 at 12:42:57PM +0800, kernel test robot wrote:
> > > Hi Alexander,
> > >
> > > FYI, the error/warning still remains.
> >
> > Alexander, either you can escalate this or just propose something to discuss.
>
> https://github.com/ClangBuiltLinux/linux/issues/1874
> Sorry, a few more fires have popped up in the meantime. Regardless of
> changes to the compiler, we still support many versions of clang for
> the kernel, so we'd need some workaround in the tests regardless. I
> saw there was already one for s390 + clang, but from this report we
> will need another. Feel free to use that link above in comments in the
> tests; we will clean those up once I have a better grasp on what's
> going on with the compiler here.
So, it's:
- not related to bitmap code,
- not only s390 issue, and
- fires with CLANG when GCOV and KASAN are enabled together.
Is that correct? If so, I can disable the test for CLANG+GCOV+KASAN
configuration unless the above is fixed.
Nick, can you please confirm?
Because it's a build breaker, I'd like to have it fixed in v6.5.
Thanks,
Yury
On Mon, Jul 17, 2023 at 11:09 AM Yury Norov <[email protected]> wrote:
>
> On Mon, Jul 17, 2023 at 09:35:49AM -0700, Nick Desaulniers wrote:
> > On Mon, Jul 17, 2023 at 3:04 AM Andy Shevchenko
> > <[email protected]> wrote:
> > >
> > > On Mon, Jul 17, 2023 at 12:42:57PM +0800, kernel test robot wrote:
> > > > Hi Alexander,
> > > >
> > > > FYI, the error/warning still remains.
> > >
> > > Alexander, either you can escalate this or just propose something to discuss.
> >
> > https://github.com/ClangBuiltLinux/linux/issues/1874
> > Sorry, a few more fires have popped up in the meantime. Regardless of
> > changes to the compiler, we still support many versions of clang for
> > the kernel, so we'd need some workaround in the tests regardless. I
> > saw there was already one for s390 + clang, but from this report we
> > will need another. Feel free to use that link above in comments in the
> > tests; we will clean those up once I have a better grasp on what's
> > going on with the compiler here.
>
> So, it's:
> - not related to bitmap code,
> - not only s390 issue, and
> - fires with CLANG when GCOV and KASAN are enabled together.
>
> Is that correct? If so, I can disable the test for CLANG+GCOV+KASAN
> configuration unless the above is fixed.
>
> Nick, can you please confirm?
Yes, and I think disabling the test for that combination is the way to
go for now. I will sort out what's going on with this config and
hopefully we can relax that combination in the future.
>
> Because it's a build breaker, I'd like to have it fixed in v6.5.
>
> Thanks,
> Yury
--
Thanks,
~Nick Desaulniers
From: Andy Shevchenko <[email protected]>
Date: Mon, 17 Jul 2023 13:04:11 +0300
> On Mon, Jul 17, 2023 at 12:42:57PM +0800, kernel test robot wrote:
>> Hi Alexander,
Hi,
>>
>> FYI, the error/warning still remains.
>
> Alexander, either you can escalate this or just propose something to discuss.
>
Sorry, I had some days off.
I've been waiting for more info from the Clang devs to understand
whether and how I should fix this.
I see that Yury submitted fix (two actually) already, so I'll go review
it now.
Thanks,
Olek