unroll: Drop the unused unrolled and unrolled_none macros
PATCH v2 1/1 unroll: Drop the unused unrolled and unrolled_none macros
unrolled and unrolled_none are object-like macros with lower-case names, and neither has had a user since commit c6594d642717 ("unroll:
add generic loop unroll helpers") added them in February 2025.
The name unrolled also breaks code that uses it for something else. On GCC the macro expands to an empty _Pragma(), so a function parameter named unrolled compiles with only -Wunknown-pragmas warnings (errors only with 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 (GCC 8 to 10 and Clang reject it).
Drop both macros, and retitle the kernel-doc comment from unrolled to unrolled_count(), the macro its usage example shows. unrolled_full and unrolled_count() stay; any clash with their names fails to build instead of compiling silently.
---
v2: drop the two unused macros instead of making all three function-like (Alexander Lobakin).
v1: https://lore.kernel.org/all/[email protected]/
Eric, this version no longer touches lib/crypto/. Would you still take it through libcrypto-next, or should it go through Andrew's -mm tree (unroll.h has no MAINTAINERS entry)?
Testing: an x86_64 defconfig build with the includers of <linux/unroll.h> enabled (BLAKE2b/s, LSMs, IMA/EVM, BPF LSM, vhost, i40e/ice/idpf; no debug info) gives byte-identical objects, modules and vmlinux before and after, with GCC 11.5, GCC 16.2 and Clang 23. In a file that includes only <linux/unroll.h>, a variable, member or parameter named unrolled or unrolled_none now builds without warnings with GCC 8.1 to 16.2 and Clang 17 to 23.
Based on libcrypto-next (20ec6916d871); applies as is to next-20261022, which has no users of the two macros either.
include/linux/unroll.h | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-)
include/linux/unroll.h +2 -11
@@ -16,7 +16,8 @@#endif /** -* unrolled - loop attributes to ask the compiler to unroll it +* unrolled_count() - loop attribute to ask the compiler to unroll it +* @n: unroll each @n iterations of the loop * * Usage: *
@@ -34,12 +35,6 @@* provides best performance and object code size. * Available only on Clang and GCC 8.x onwards. */ - -/* Ask the compiler to pick an optimal unroll count, Clang only */ -#define unrolled \ - __pick_unrolled(clang loop unroll(enable), /* nothing */) - -/* Unroll each @n iterations of the loop */ #define unrolled_count (n) \ __pick_unrolled(clang loop unroll_count(n), GCC unroll n)
@@ -47,10 +42,6 @@#define unrolled_full \ __pick_unrolled(clang loop unroll(full), GCC unroll 65534) -/* Never unroll the loop */ -#define unrolled_none \ - __pick_unrolled(clang loop unroll(disable), GCC unroll 1) - #define UNROLL(N, MACRO, args...) CONCATENATE(__UNROLL_, N)(MACRO, args) #define __UNROLL_0(MACRO, args...)
base-commit: 20ec6916d8712e84d58e8c688a25cd368ddeb82b
Signature · 1 line
2.34.1
Quoted 14 lines · Tzu-Ching Yang
unrolled and
unrolled_noneare object-like macros with lower-case names, and neither has had a user since commitc6594d642717("unroll:
add generic loop unroll helpers") added them in February 2025.The name unrolled also breaks code that uses it for something else. On GCC the macro expands to an empty
_Pragma(), so a function parameter named unrolled compiles with only -Wunknown-pragmas warnings (errors only withCONFIG_WERROR) and silently loses its name:int add(int unrolled, int x) { return unrolled + x; }builds as "return x;" with GCC 11 to 16 (GCC 8 to 10 and Clang reject it).
Quoted 8 lines
Drop both macros, and retitle the kernel-doc comment from unrolled to
unrolled_count(), the macro its usage example shows.unrolled_fullandunrolled_count()stay; any clash with their names fails to build instead of compiling silently.Suggested-by Alexander Lobakin <[email protected]>Signed-off-by Tzu-Ching Yang <[email protected]>
Quoted 7 lines
v2: drop the two unused macros instead of making all three function-like (Alexander Lobakin).
v1: https://lore.kernel.org/all/[email protected]/Eric, this version no longer touches
lib/crypto/. Would you still take it through libcrypto-next, or should it go through Andrew's -mm tree (unroll.hhas noMAINTAINERSentry)?
Either way is fine with me. It's one of the unowned files, which are always problematic. If Andrew hasn't taken it by the time -rc1 rolls around, I'll apply it to libcrypto-next: it's at least somewhat related, given that lib/crypto/ is one of the few users of this file.
- Eric
Quoted 30 lines · On Sat, 24 Oct 2026 11:15:20 -0700 Eric Biggers <[email protected]> wrote:
Quoted 14 lines · Tzu-Ching Yang
unrolled and
unrolled_noneare object-like macros with lower-case names, and neither has had a user since commitc6594d642717("unroll:
add generic loop unroll helpers") added them in February 2025.The name unrolled also breaks code that uses it for something else. On GCC the macro expands to an empty
_Pragma(), so a function parameter named unrolled compiles with only -Wunknown-pragmas warnings (errors only withCONFIG_WERROR) and silently loses its name:int add(int unrolled, int x) { return unrolled + x; }builds as "return x;" with GCC 11 to 16 (GCC 8 to 10 and Clang reject it).
Quoted 8 lines
Drop both macros, and retitle the kernel-doc comment from unrolled to
unrolled_count(), the macro its usage example shows.unrolled_fullandunrolled_count()stay; any clash with their names fails to build instead of compiling silently.Suggested-by Alexander Lobakin <[email protected]>Signed-off-by Tzu-Ching Yang <[email protected]>Reviewed-by Eric Biggers <[email protected]>Quoted 4 lines
v2: drop the two unused macros instead of making all three function-like (Alexander Lobakin).
v1: https://lore.kernel.org/all/[email protected]/
Quoted 8 lines
Quoted 3 lines
Eric, this version no longer touches
lib/crypto/. Would you still take it through libcrypto-next, or should it go through Andrew's -mm tree (unroll.hhas noMAINTAINERSentry)?Either way is fine with me. It's one of the unowned files, which are always problematic. If Andrew hasn't taken it by the time -rc1 rolls around, I'll apply it to libcrypto-next: it's at least somewhat related, given that
lib/crypto/is one of the few users of this file.
That sounds good.
I'm only looking at bugfixes at present. Non-fixes get parked for consideration after -rc1.
Eric Biggers
AppliedQuoted 22 lines · Tzu-Ching Yang
unrolled and
unrolled_noneare object-like macros with lower-case names, and neither has had a user since commitc6594d642717("unroll:
add generic loop unroll helpers") added them in February 2025.The name unrolled also breaks code that uses it for something else. On GCC the macro expands to an empty
_Pragma(), so a function parameter named unrolled compiles with only -Wunknown-pragmas warnings (errors only withCONFIG_WERROR) and silently loses its name:int add(int unrolled, int x) { return unrolled + x; }builds as "return x;" with GCC 11 to 16 (GCC 8 to 10 and Clang reject it).
Drop both macros, and retitle the kernel-doc comment from unrolled to
unrolled_count(), the macro its usage example shows.unrolled_fullandunrolled_count()stay; any clash with their names fails to build instead of compiling silently.Suggested-by Alexander Lobakin <[email protected]>Signed-off-by Tzu-Ching Yang <[email protected]>
Quoted 8 lines
---
v2: drop the two unused macros instead of making all three function-like (Alexander Lobakin).
v1: https://lore.kernel.org/all/[email protected]/Eric, this version no longer touches
lib/crypto/. Would you still take it through libcrypto-next, or should it go through Andrew's -mm tree (unroll.hhas noMAINTAINERSentry)?
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=libcrypto-next
- Eric