On Wed, 4 Oct 2017 18:50:04 -0700, Manoj Gupta wrote: > On Wed, Oct 4, 2017 at 5:56 PM, Jakub Kicinski wrote: > > On Wed, 4 Oct 2017 17:38:22 -0700, Manoj Gupta wrote: > >> On Wed, Oct 4, 2017 at 4:25 PM, Jakub Kicinski wrote: > >> > On Wed, 4 Oct 2017 16:16:49 -0700, Matthias Kaehlcke wrote: > >> >> > > Thanks for the suggestion. This seems a viable alternative if David > >> >> > > and the NFP owners can live without the extra checking provided by > >> >> > > __BF_FIELD_CHECK. > >> >> > > >> >> > The reason the __BF_FIELD_CHECK refuses to compile non-constant masks > >> >> > is that it will require runtime ffs on the mask, which is potentially > >> >> > costly. I would also feel quite stupid adding those macros to the nfp > >> >> > driver, given that I specifically created the bitfield.h header to not > >> >> > have to reimplement these in every driver I write/maintain. > >> >> > >> >> That make sense, thanks for providing more context. > >> >> > >> >> > Can you please test the patch I provided in the other reply? > >> >> > >> >> With this patch there are no errors when building the kernel with > >> >> clang. > >> > > >> > Cool, thanks for checking! I will run it through full tests and queue > >> > for upstreaming :) > >> > >> Just to let you know, using __BF_FIELD_CHECK macro will not Link with > >> -O0 (GCC or Clang) since references to __compiletime_assert_xxx will > >> not be cleaned up. > > > > Do you mean the current nfp_eth_set_bit_config() will not work with -O0 > > on either complier, or any use of __BF_FIELD_CHECK() will not compile > > with -O0? > > Any use of __BF_FIELD_CHECK. The code will compile but not link since > calls to ____compiletime_assert_xxx (added by compiletime_assert > macro) will not be removed in -O0.
Why would that be, it's just a macro? Does it by extension mean any use of BUILD_BUG_ON_MSG() will not compile with -O0?