PR #23653 opened by Martin Storsjö (mstorsjo) URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23653 Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23653.patch
Before ced4a6ebc9e7cd92d0ca9b9fb8f9d1013d23cbfa, we used constants in the form HWCAP_NEON. In that commit, they were renamed to HWCAP_ARM_NEON, to match the pattern used for aarch64 and PPC. On PPC our naming is entirely custom to us, upstream headers (from e.g. glibc) use an entirely different naming. On aarch64, we use names similar to the system headers, where they are named e.g. HWCAP_CRC32, but we add an extra prefix, naming them HWCAP_AARCH64_CRC32, to avoid any potential conflict and redefinition issues. (In practice, this isn't needed - both glibc, musl and BSDs provide the aarch64 HWCAP_ defines with the same names and same literal expansion.) However, on ARM, the landscape of the HWCAP defines is much less consistent. On glibc, <bits/hwcap.h> (which gets included by <sys/auxv.h>) provides most constants with an HWCAP_ARM_ prefix. (The couple newest constants lack that prefix though.) The kernel headers, in <asm/hwcap.h>) define them with just a HWCAP_ prefix, i.e. HWCAP_ARM_NEON vs HWCAP_NEON. For the actual expansion, <asm/hwcap.h> defines HWCAP_NEON as (1 << 12), while glibc <bits/hwcap.h> defines HWCAP_ARM_NEON as 4096. Musl's <bits/hwcap.h> defines both HWCAP_NEON and HWCAP_ARM_NEON, as (1 << 12). The BSDs define HWCAP_NEON in <elf.h>, defined as 0x00001000. Thus, all system headers define the constant with differing expansions. And they differ in which name they expose for the constants. But we provide our definitions in any case. Due to all this, wrap our definitions in #ifndefs, to avoid warnings about redefining the constants on glibc. # Summary of changes Briefly describe what this PR does and why. <!-- If this PR requires new FATE test samples, attach them to the PR and list their target paths below (relative to the fate-suite root). Attached filenames must match the sample's filename: ```fate-samples # e.g. vorbis/new-sample.ogg ``` --> From b97f67ad2d68a77af91481a867cf0ee87923b233 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Martin=20Storsj=C3=B6?= <[email protected]> Date: Tue, 30 Jun 2026 13:39:09 +0300 Subject: [PATCH] arm: Avoid warnings about redefining HWCAP constants Before ced4a6ebc9e7cd92d0ca9b9fb8f9d1013d23cbfa, we used constants in the form HWCAP_NEON. In that commit, they were renamed to HWCAP_ARM_NEON, to match the pattern used for aarch64 and PPC. On PPC our naming is entirely custom to us, upstream headers (from e.g. glibc) use an entirely different naming. On aarch64, we use names similar to the system headers, where they are named e.g. HWCAP_CRC32, but we add an extra prefix, naming them HWCAP_AARCH64_CRC32, to avoid any potential conflict and redefinition issues. (In practice, this isn't needed - both glibc, musl and BSDs provide the aarch64 HWCAP_ defines with the same names and same literal expansion.) However, on ARM, the landscape of the HWCAP defines is much less consistent. On glibc, <bits/hwcap.h> (which gets included by <sys/auxv.h>) provides most constants with an HWCAP_ARM_ prefix. (The couple newest constants lack that prefix though.) The kernel headers, in <asm/hwcap.h>) define them with just a HWCAP_ prefix, i.e. HWCAP_ARM_NEON vs HWCAP_NEON. For the actual expansion, <asm/hwcap.h> defines HWCAP_NEON as (1 << 12), while glibc <bits/hwcap.h> defines HWCAP_ARM_NEON as 4096. Musl's <bits/hwcap.h> defines both HWCAP_NEON and HWCAP_ARM_NEON, as (1 << 12). The BSDs define HWCAP_NEON in <elf.h>, defined as 0x00001000. Thus, all system headers define the constant with differing expansions. And they differ in which name they expose for the constants. But we provide our definitions in any case. Due to all this, wrap our definitions in #ifndefs, to avoid warnings about redefining the constants on glibc. --- libavutil/arm/cpu.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/libavutil/arm/cpu.c b/libavutil/arm/cpu.c index 2e2977efc9..2f6d558380 100644 --- a/libavutil/arm/cpu.c +++ b/libavutil/arm/cpu.c @@ -46,13 +46,25 @@ #define AT_HWCAP 16 #endif -/* Relevant HWCAP values from kernel headers */ +/* Relevant HWCAP values from <sys/auxv.h> that includes <bits/hwcap.h> */ +#ifndef HWCAP_ARM_VFP #define HWCAP_ARM_VFP (1 << 6) +#endif +#ifndef HWCAP_ARM_EDSP #define HWCAP_ARM_EDSP (1 << 7) +#endif +#ifndef HWCAP_ARM_THUMBEE #define HWCAP_ARM_THUMBEE (1 << 11) +#endif +#ifndef HWCAP_ARM_NEON #define HWCAP_ARM_NEON (1 << 12) +#endif +#ifndef HWCAP_ARM_VFPv3 #define HWCAP_ARM_VFPv3 (1 << 13) +#endif +#ifndef HWCAP_ARM_TLS #define HWCAP_ARM_TLS (1 << 15) +#endif static int get_auxval(uint32_t *hwcap) { -- 2.52.0 _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
