On Tue, Aug 26, 2025 at 07:13:03PM -0700, Kees Cook wrote:
> On Tue, Aug 26, 2025 at 09:24:04PM -0400, Yury Norov wrote:
> > On Tue, Aug 26, 2025 at 09:56:06AM -0700, Kees Cook wrote:
> > > On Tue, Aug 26, 2025 at 03:08:59PM +0200, Rasmus Villemoes wrote:
> > > > If __builtin_arc_fls() simply doesn't qualify for attr_const for
> > > > $reason, I think it would be good to have that documented in the commit
> > > > msg. If it does, I think a gcc ticket and link to that would be in
> > > > order.
> > >
> > > I already sent the patch to fix it. :)
> > >
> > > https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693273.html
> >
> > I'm OK taking the patch if it fixes real problem for you, but it looks
> > more like a GCC problem, right? Is Clang also affected?
>
> Without it, KUnit testing of ffs/fls fails on arc. Clang is not
That's a solid point. Can you please notice it in changelog too?
> affected. Even with the GCC fix landed, all older GCCs with still fail,
> and since it provides a improved code generation for arc, it seems worth
> it (compile-time-calculable values will be emitted instead of always
> running the arc instructions).
Yep. This is what I meant. Once the fix is landed, we will not need this
code. When the minimal supported GCC version will become greater than
one that has the fix applied, it will be much easier to spot this hack
and drop it, if we mention that explicitly.
Something like that:
#if IS_ENABLED(CONFIG_CC_IS_GCC) && CONFIG_GCC_VERSION < XXX
if ( __builtin_constant_p(x))
return x ? BITS_PER_LONG - 1 - __builtin_clzl(x) : 0;
#endif
> > If, say, Clang is not affected, and you expect that newer GCC versions
> > will not be affected too, let's protect the new code with a proper
> > ifdefery, so that it will be easier to drop the workaround later?
>
> I think the codegen benefit is worth it as I have it.
That's I'm surely agree.
