This is an automated email from the git hooks/post-receive script.

Git pushed a commit to branch master
in repository ffmpeg.

The following commit(s) were added to refs/heads/master by this push:
     new 7f6b35d6c8 arm: Avoid warnings about redefining HWCAP constants
7f6b35d6c8 is described below

commit 7f6b35d6c804ed8d1bc517c33044f075d72852ba
Author:     Martin Storsjö <[email protected]>
AuthorDate: Tue Jun 30 13:39:09 2026 +0300
Commit:     Martin Storsjö <[email protected]>
CommitDate: Thu Jul 16 21:39:47 2026 +0000

    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)
 {

_______________________________________________
ffmpeg-cvslog mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to