aboutsummaryrefslogtreecommitdiffstats
path: root/libavutil/mem_internal.h
Commit message (Collapse)AuthorAgeFilesLines
* avutil: Fix linking x86 asm constants with Clang in MSVC modeMartin Storsjö2025-06-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This fixes building with Clang in MSVC mode, for x86, which was broken in 6e49b8699657b808b7dc80033f2c3f2d0e029fa3 (in Nov 2024); previously it failed with undefined symbols for the constants defined with DECLARE_ASM_CONST, accessed via inline assembly. Before 57861911a34e1c33796be97f2b2f44e05fffd647, there was an #elif defined(__GNUC__) || defined(__clang__) case before the #elif defined(_MSC_VER) case for defining DECLARE_ASM_CONST, which included av_used. (This case included the explicit "defined(__clang__)" since f637046d3134a331e4b5a7243ac3dfb92735b8a5.) After 57861911a34e1c33796be97f2b2f44e05fffd647, it used the generic definition of DECLARE_ASM_CONST that also included av_used - which also worked for Clang in MSVC mode. But after 6e49b8699657b808b7dc80033f2c3f2d0e029fa3, Clang in MSVC mode ended up using the MSVC specific variant which lacked the av_used declaration, causing linker errors due to undefined symbols. Signed-off-by: Martin Storsjö <martin@martin.st>
* avcodec/x86/vp9: Add AVX-512ICL for 16x16 and 32x32 8bpc inverse transformsHenrik Gramner2025-05-191-0/+2
|
* avutil/mem_internal: Don't include stdalign.h on MSVCMartin Storsjö2024-12-181-0/+2
| | | | | | | | | | | | | | | It's currently actually not used in MSVC builds, since 6e49b8699657b808b7dc80033f2c3f2d0e029fa3. Older versions of MSVC (or, in particular, older versions of UCRT) don't have stdalign.h; it's available since WinSDK 10.0.20348.0; such a new enough version has been installed by default only since MSVC 2022 17.4 and newer. With this change, ffmpeg can still be built with MSVC 2019 16.8 (v19.28). Signed-off-by: Martin Storsjö <martin@martin.st>
* avutil/mem_internal: Don't use alignas for MSVCZhao Zhili2024-12-021-0/+4
| | | | | | | MSVC messed up standard C features, again. Signed-off-by: Zhao Zhili <zhilizhao@tencent.com> Reviewed-by: James Almer <jamrial@gmail.com>
* avutil/mem_internal: local align should always workZhao Zhili2024-11-291-24/+4
| | | | Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
* avutil/mem_internal: define DECLARE_ALIGNED as C11's alignasZhao Zhili2024-11-291-19/+8
| | | | | | | | | alignas is portable than compiler's specific __attribute__. It do have a limitation, that alignas don't support specify aligment on the declarations of struct (it works for specify alignment on struct fields), which only used by avcodec/cavs, and is removed now. Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
* avutil/mem_internal: Remove unneeded headersAndreas Rheinhardt2024-03-011-2/+0
| | | | | | Unneeded since 21814a70db08999efee49531c67f62e2678a62f4. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/mem: limit alignment to maximum simd alignTimo Rothenpieler2024-02-271-5/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs, which then end up heap-allocated. By declaring any variable in a struct, or tree of structs, to be 32 byte aligned, it allows the compiler to safely assume the entire struct itself is also 32 byte aligned. This might make the compiler emit code which straight up crashes or misbehaves in other ways, and at least in one instances is now documented to actually do (see ticket 10549 on trac). The issue there is that an unrelated variable in SingleChannelElement is declared to have an alignment of 32 bytes. So if the compiler does a copy in decode_cpe() with avx instructions, but ffmpeg is built with --disable-avx, this results in a crash, since the memory is only 16 byte aligned. Mind you, even if the compiler does not emit avx instructions, the code is still invalid and could misbehave. It just happens not to. Declaring any variable in a struct with a 32 byte alignment promises 32 byte alignment of the whole struct to the compiler. This patch limits the maximum alignment to the maximum possible simd alignment according to configure. While not perfect, it at the very least gets rid of a lot of UB, by matching up the maximum DECLARE_ALIGNED value with the alignment of heap allocations done by lavu.
* Revert "avutil/mem: limit alignment to maximum simd align"Timo Rothenpieler2024-02-091-8/+6
| | | | | | Patch was not intended to be part of the set it got pushed with. This reverts commit 6154137b186734961726ae538ab5cbe287bab163.
* avutil/mem: limit alignment to maximum simd alignTimo Rothenpieler2024-02-091-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs, which then end up heap-allocated. By declaring any variable in a struct, or tree of structs, to be 32 byte aligned, it allows the compiler to safely assume the entire struct itself is also 32 byte aligned. This might make the compiler emit code which straight up crashes or misbehaves in other ways, and at least in one instances is now documented to actually do (see ticket 10549 on trac). The issue there is that an unrelated variable in SingleChannelElement is declared to have an alignment of 32 bytes. So if the compiler does a copy in decode_cpe() with avx instructions, but ffmpeg is built with --disable-avx, this results in a crash, since the memory is only 16 byte aligned. Mind you, even if the compiler does not emit avx instructions, the code is still invalid and could misbehave. It just happens not to. Declaring any variable in a struct with a 32 byte alignment promises 32 byte alignment of the whole struct to the compiler. This patch limits the maximum alignment to the maximum possible simd alignment according to configure. While not perfect, it at the very least gets rid of a lot of UB, by matching up the maximum DECLARE_ALIGNED value with the alignment of heap allocations done by lavu.
* avutil: remove FF_API_DECLARE_ALIGNEDJames Almer2023-02-091-2/+0
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/mem_internal: Fix headersAndreas Rheinhardt2022-08-241-1/+2
| | | | | | | Including avassert.h is unnecessary since commit 786be70e28fe739b8e49893fa13ae4652a68d1ea. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/mem: make ff_fast_malloc() internal to mem.cJames Almer2021-05-271-18/+0
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* lavu/mem: move the DECLARE_ALIGNED macro family to mem_internal on next+1 bumpAnton Khirnov2021-01-011-0/+70
| | | | They are not properly namespaced and not intended for public use.
* lavu: move LOCAL_ALIGNED from internal.h to mem_internal.hAnton Khirnov2021-01-011-0/+42
| | | | That is a more appropriate place for it.
* avutil/mem_internal: add missing header includesJames Almer2015-07-131-0/+3
| | | | | | | Fixes make checkheaders Reviewed-by: Michael Niedermayer <michaelni@gmx.at> Signed-off-by: James Almer <jamrial@gmail.com>
* Factor duplicated ff_fast_malloc() out into mem_internal.hMichael Niedermayer2015-07-131-0/+42
internal.h is difficult to use due to circular dependancies mem.h is a public header ff_* is not public Alternative solutions probably are possible too Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 20:45:56 +0000