On 06/09/2024 1:27 am, Andrew Cooper wrote: > On 06/09/2024 12:08 am, Stefano Stabellini wrote: >> On Wed, 4 Sep 2024, Andrew Cooper wrote: >>> ... and drop generic_hweight32(). >>> >>> As noted previously, the only two users of hweight32() are in __init paths. >>> >>> The int-optimised form of generic_hweight() is only two instructions shorter >>> than the long-optimised form, and even then only on architectures which lack >>> fast multiplication, so there's no point providing an int-optimised form. >>> >>> No functional change. >>> >>> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> >>> Acked-by: Jan Beulich <jbeul...@suse.com> >> The patch is OK: >> >> Acked-by: Stefano Stabellini <sstabell...@kernel.org> > Thanks. > >> I was looking at docs/misra/C-language-toolchain.rst to make sure >> everything is listed there. We have attr_const as "__const__" noted >> among "Non-standard tokens". >> >> Looks like we need to add __always_inline__ ? > Luckily, no. > > First, the __const__ referred to there is GCC's alternative spelling of > the regular C 'const' keyword, and not the function attribute by the > same name. > > But, non-standard tokens are about things which survive full > preprocessing and are still not standard C. In this case, it's the > __attribute__ that matters, not what's in it, and this is why we don't > have a hundreds of rows in that table for __attribute__((foo, bar, baz)). > > That said, I think f96e2f64576cdbb147391c7cb399d393385719a9 probably > should have removed the entire row including __const__ seeing as AFAICT > the last user in Xen was dropped in 1aa3c54a31a5 in 2008
Hmm. Eclair disagrees. https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/7765315981 Now I'm completely confused as to why __const__ matters and everything else inside an __attribute__(()) apparently doesn't. CC-ing some folk. Any ideas? ~Andrew
