[akpm-mm:mm-nonmm-unstable 52/52] lib/bch.c:317:undefined reference to `__paritydi2'

[akpm-mm:mm-nonmm-unstable 52/52] lib/bch.c:317:undefined reference to `__paritydi2'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
head:   1b9f78ccbffefb107cd92e20cfccd03ff2fa9d0e
commit: 1b9f78ccbffefb107cd92e20cfccd03ff2fa9d0e [52/52] lib/bch.c: use __builtin_parity() when available
config: arm64-randconfig-002-20250131 (https://download.01.org/0day-ci/archive/20250131/202501312159.l6jNRaYy-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250131/202501312159.l6jNRaYy-lkp@intel.com/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 <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202501312159.l6jNRaYy-lkp@intel.com/

All errors (new ones prefixed by >>):

   aarch64-linux-ld: lib/bch.o: in function `parity':
>> lib/bch.c:317:(.text+0x10e8): undefined reference to `__paritydi2'
>> lib/bch.c:317:(.text+0x10e8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__paritydi2'


vim +317 lib/bch.c

   313	
   314	static inline int parity(unsigned int x)
   315	{
   316	#if __has_builtin(__builtin_parity)
 > 317		return __builtin_parity(x);
   318	#else
   319		/*
   320		 * public domain code snippet, lifted from
   321		 * http://www-graphics.stanford.edu/~seander/bithacks.html
   322		 */
   323		x ^= x >> 1;
   324		x ^= x >> 2;
   325		x = (x & 0x11111111U) * 0x11111111U;
   326		return (x >> 28) & 1;
   327	#endif
   328	}
   329	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [akpm-mm:mm-nonmm-unstable 52/52] lib/bch.c:317:undefined reference to `__paritydi2'

[Uros Bizjak]

On Fri, Jan 31, 2025 at 2:12 PM kernel test robot <lkp@intel.com> wrote:
>
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
> head:   1b9f78ccbffefb107cd92e20cfccd03ff2fa9d0e
> commit: 1b9f78ccbffefb107cd92e20cfccd03ff2fa9d0e [52/52] lib/bch.c: use __builtin_parity() when available
> config: arm64-randconfig-002-20250131 (https://download.01.org/0day-ci/archive/20250131/202501312159.l6jNRaYy-lkp@intel.com/config)
> compiler: aarch64-linux-gcc (GCC) 14.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250131/202501312159.l6jNRaYy-lkp@intel.com/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 <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202501312159.l6jNRaYy-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
>    aarch64-linux-ld: lib/bch.o: in function `parity':
> >> lib/bch.c:317:(.text+0x10e8): undefined reference to `__paritydi2'
> >> lib/bch.c:317:(.text+0x10e8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__paritydi2'

This config for some reason generates a call to the library function.
But I have tested this with a crosscompiler:

       fmov    s31, w0
       cnt     v31.8b, v31.8b
       addv    b31, v31.8b
       fmov    w0, s31
       and     w0, w0, 1
       ret

It looks that __has_builtin() does not mean that there will be no call
to a library function?!

Uros.

>
> vim +317 lib/bch.c
>
>    313
>    314  static inline int parity(unsigned int x)
>    315  {
>    316  #if __has_builtin(__builtin_parity)
>  > 317          return __builtin_parity(x);
>    318  #else
>    319          /*
>    320           * public domain code snippet, lifted from
>    321           * http://www-graphics.stanford.edu/~seander/bithacks.html
>    322           */
>    323          x ^= x >> 1;
>    324          x ^= x >> 2;
>    325          x = (x & 0x11111111U) * 0x11111111U;
>    326          return (x >> 28) & 1;
>    327  #endif
>    328  }
>    329
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki

Re: [akpm-mm:mm-nonmm-unstable 52/52] lib/bch.c:317:undefined reference to `__paritydi2'

[Pedro Falcato]

On Fri, Jan 31, 2025 at 1:23 PM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Fri, Jan 31, 2025 at 2:12 PM kernel test robot <lkp@intel.com> wrote:
> >
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
> > head:   1b9f78ccbffefb107cd92e20cfccd03ff2fa9d0e
> > commit: 1b9f78ccbffefb107cd92e20cfccd03ff2fa9d0e [52/52] lib/bch.c: use __builtin_parity() when available
> > config: arm64-randconfig-002-20250131 (https://download.01.org/0day-ci/archive/20250131/202501312159.l6jNRaYy-lkp@intel.com/config)
> > compiler: aarch64-linux-gcc (GCC) 14.2.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250131/202501312159.l6jNRaYy-lkp@intel.com/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 <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202501312159.l6jNRaYy-lkp@intel.com/
> >
> > All errors (new ones prefixed by >>):
> >
> >    aarch64-linux-ld: lib/bch.o: in function `parity':
> > >> lib/bch.c:317:(.text+0x10e8): undefined reference to `__paritydi2'
> > >> lib/bch.c:317:(.text+0x10e8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__paritydi2'
>
> This config for some reason generates a call to the library function.
> But I have tested this with a crosscompiler:
>
>        fmov    s31, w0
>        cnt     v31.8b, v31.8b
>        addv    b31, v31.8b
>        fmov    w0, s31
>        and     w0, w0, 1
>        ret
>
> It looks that __has_builtin() does not mean that there will be no call
> to a library function?!

Yep, __builtin functions aren't strictly required to be inlined and
can generate a library call if the compiler so chooses (how often this
happens depends on the optimization level and architecture).
e.g: https://godbolt.org/z/zKPb9hbaM

-- 
Pedro

Re: [akpm-mm:mm-nonmm-unstable 52/52] lib/bch.c:317:undefined reference to `__paritydi2'

[Uros Bizjak]

On Fri, Jan 31, 2025 at 3:34 PM Pedro Falcato <pedro.falcato@gmail.com> wrote:
>
> On Fri, Jan 31, 2025 at 1:23 PM Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > On Fri, Jan 31, 2025 at 2:12 PM kernel test robot <lkp@intel.com> wrote:
> > >
> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
> > > head:   1b9f78ccbffefb107cd92e20cfccd03ff2fa9d0e
> > > commit: 1b9f78ccbffefb107cd92e20cfccd03ff2fa9d0e [52/52] lib/bch.c: use __builtin_parity() when available
> > > config: arm64-randconfig-002-20250131 (https://download.01.org/0day-ci/archive/20250131/202501312159.l6jNRaYy-lkp@intel.com/config)
> > > compiler: aarch64-linux-gcc (GCC) 14.2.0
> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250131/202501312159.l6jNRaYy-lkp@intel.com/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 <lkp@intel.com>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202501312159.l6jNRaYy-lkp@intel.com/
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > >    aarch64-linux-ld: lib/bch.o: in function `parity':
> > > >> lib/bch.c:317:(.text+0x10e8): undefined reference to `__paritydi2'
> > > >> lib/bch.c:317:(.text+0x10e8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__paritydi2'
> >
> > This config for some reason generates a call to the library function.
> > But I have tested this with a crosscompiler:
> >
> >        fmov    s31, w0
> >        cnt     v31.8b, v31.8b
> >        addv    b31, v31.8b
> >        fmov    w0, s31
> >        and     w0, w0, 1
> >        ret
> >
> > It looks that __has_builtin() does not mean that there will be no call
> > to a library function?!
>
> Yep, __builtin functions aren't strictly required to be inlined and
> can generate a library call if the compiler so chooses (how often this
> happens depends on the optimization level and architecture).
> e.g: https://godbolt.org/z/zKPb9hbaM

Thanks for the example!

I have to retract the patch.

Thanks,
Uros.