El Wed, Oct 04, 2017 at 07:13:26PM -0700 Manoj Gupta ha dit: > On Wed, Oct 4, 2017 at 7:06 PM, Jakub Kicinski > <jakub.kicin...@netronome.com> wrote: > > 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? > > You have to look at the the code added once the macro is expanded :). > Please look at implementation of compiletime_assert at > http://elixir.free-electrons.com/linux/v4.12.14/source/include/linux/compiler.h#L507 > It creates a call to __compiler_assert_xxx inside a loop which is not > cleaned up in -O0.
I just saw that v4.14 will have a fix for that: commit c03567a8e8d5cf2aaca40e605c48f319dc2ead57 Author: Joe Stringer <j...@ovn.org> Date: Thu Aug 31 16:15:33 2017 -0700 include/linux/compiler.h: don't perform compiletime_assert with -O0 Obviously this means that the checks aren't performed, however that shouldn't be an issue since AFAIK the kernel doesn't officially support -O0 builds in the first place.
