Re: [PATCH] unroll: Make unrolled, unrolled_full and unrolled_none function-like

[Tzu-Ching Yang]

On Wed, Oct 21, 2026 at 05:02:30PM +0200, Alexander Lobakin wrote:
> We have either plain-named attributes like `notrace` (BTW what if you
> name your variable as `notrace`?) or underscored like `__always_inline`.
> If you really need to name your variables `unrolled`, then I'd expect
> changing these macros to `__unrolled` etc, not to `unrolled()`.
> Although I'm not sure we really need it, there's tons of such macros in
> the kernel -- try naming your variable `current`.

A variable named notrace or current fails to build, and so does one
named unrolled_full. The one that worries me is unrolled: on GCC it
expands to an empty _Pragma(), so a function parameter of that name
compiles with only -Wunknown-pragmas warnings (not errors without
CONFIG_WERROR) and silently loses its name:

	int add(int unrolled, int x) { return unrolled + x; }

builds as "return x;" with GCC 11 to 16 (Clang rejects it). Nothing in
the tree does that today; this is about not leaving the trap for the
next file that includes <linux/unroll.h>.

I see three ways to close it:

1. This patch: make the three macros function-like, as unrolled_count()
   and UNROLL() already are. Variables, members and parameters with
   these names are then left alone. Cost: an attribute that looks like
   a call.

2. Your suggestion: rename them to __unrolled, __unrolled_full and
   __unrolled_none, like __always_inline. The attribute syntax stays,
   and nobody names a variable that way. Cost: inconsistent names,
   unless unrolled_count() is renamed as well.

3. Drop unrolled and unrolled_none, which have no users. This removes
   the silent case and touches only unroll.h; a variable named
   unrolled_full still fails to build, but with an error, not silently.

Which would you prefer? I can send v2 for 2 or 3, or leave 1 as posted.

Thanks,
Tzu-Ching