[libc-commits] [libc] [libc][AArch64] Avoid -Wshadow warnings about uint128_t etc (PR #212227)
Simon Tatham via libc-commits
libc-commits at lists.llvm.org
Mon Jul 27 04:29:44 PDT 2026
https://github.com/statham-arm created https://github.com/llvm/llvm-project/pull/212227
`aarch64/inline_memset.h` defines type aliases `uint128_t`, `uint256_t` and `uint512_t` at file scope. `aarch64/inline_memmove.h`, alongside it, defines the same aliases at function scope. If both headers are included by the same source file, this can lead to a warning about the function-scope aliases shadowing the file-scope ones, which turns into a compile error if you build with `clang -Werror -Wshadow`.
Commit a81db64570f94c2 (PR #210895) exposed this latent compile failure, by making `CPP/string.h` include both files. But there's nothing wrong with that, so the right fix is to make it _safe_ to include both files, not to stop doing it.
This commit moves the function-scope aliases in memmove up to file scope. That makes them duplicate definitions in the _same_ scope, which doesn't cause the same error.
Other options would be to move the memset aliases down into function scope (duplicating them in two functions), or to move them into a tiny AArch64-specific header file with an include guard. Both of those are more intrusive than this fix.
>From 359eaa04f4e6f781f32ed01157d253762c9a80ca Mon Sep 17 00:00:00 2001
From: Simon Tatham <simon.tatham at arm.com>
Date: Mon, 27 Jul 2026 11:57:45 +0100
Subject: [PATCH] [libc][AArch64] Avoid -Wshadow warnings about uint128_t etc
`aarch64/inline_memset.h` defines type aliases `uint128_t`,
`uint256_t` and `uint512_t` at file scope. `aarch64/inline_memmove.h`,
alongside it, defines the same aliases at function scope. If both
headers are included by the same source file, this can lead to a
warning about the function-scope aliases shadowing the file-scope
ones, which turns into a compile error if you build with `clang
-Werror -Wshadow`.
Commit a81db64570f94c2 (PR #210895) exposed this latent compile
failure, by making `CPP/string.h` include both files. But there's
nothing wrong with that, so the right fix is to make it _safe_ to
include both files, not to stop doing it.
This commit moves the function-scope aliases in memmove up to file
scope. That makes them duplicate definitions in the _same_ scope,
which doesn't cause the same error.
Other options would be to move the memset aliases down into function
scope (duplicating them in two functions), or to move them into a tiny
AArch64-specific header file with an include guard. Both of those are
more intrusive than this fix.
---
libc/src/string/memory_utils/aarch64/inline_memmove.h | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libc/src/string/memory_utils/aarch64/inline_memmove.h b/libc/src/string/memory_utils/aarch64/inline_memmove.h
index d8d276966fd27..6f5f53029985a 100644
--- a/libc/src/string/memory_utils/aarch64/inline_memmove.h
+++ b/libc/src/string/memory_utils/aarch64/inline_memmove.h
@@ -17,10 +17,11 @@
namespace LIBC_NAMESPACE_DECL {
+using uint128_t = generic_v128;
+using uint256_t = generic_v256;
+using uint512_t = generic_v512;
+
LIBC_INLINE void inline_memmove_aarch64(Ptr dst, CPtr src, size_t count) {
- using uint128_t = generic_v128;
- using uint256_t = generic_v256;
- using uint512_t = generic_v512;
if (count == 0)
return;
if (count == 1)
More information about the libc-commits
mailing list