None of them are specific to the YASM assembler.

(Cherry-picked from libav commit 39e208f4)
Signed-off-by: James Almer <jamrial@gmail.com>

None of them are specific to the YASM assembler.

See merge commit '39d6d361'.

These warnings conflict with system macros on Solaris, producing
truckloads of warnings about macro redefinition.

Libav, for some reason, merged this as a public API function. This will
aid in future merges.

A define is left for backwards compat, just in case some person
used it, since it is in a public header.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Fixes: 451b3e0cf956c0bd2f27ed753ac24050/asan_heap-oob_2873c01_3231_7ed10a9464d15f0d57277f5917c566a8.AVI

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

swscale/x86/rgb2rgb_template: Fallback to mmx in interleaveBytes() if the alignment is insufficient for SSE*

This also as a sideeffect fixes the non aligned case
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes Ticket5013
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>

Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>

Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes Ticket4151
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This avoids out of array accesses
Should fix Ticket3451
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

might fix ticket 3410
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Automatically change MANGLE() into named inline asm operands when direct symbol reference in inline asm are not supported.

This is part of the patch-set for intel C inline asm on windows support
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

This does not yet include any actual AVX code
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Found-by: iive
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This does not yet include any actual AVX code
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes ticket #2477.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This simplifies the code and improves quality at the expense of a slight
slowdown of a rarely used function (no fate test uses it).
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

As the function arguments change, we also change the function name
to ensure that anyone using this (non public) function doesnt end
with hard to debug crashes. The new name also has a proper prefix.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

To access data at multiple fixed offsets from a base address, this
code uses a single "m" operand and code of the form "32%0", relying on
the memory operand instantiation having no displacement, giving a final
result of the form "32(%rax)".  If the compiler uses a register and
displacement, e.g. "64(%rax)", the end result becomes "3264(%rax)",
which obviously does not work.

Replacing the "m" operands with "r" operands allows safe addition of a
displacement.  In theory, multiple memory operands could use a shared
base register with different index registers, "(%rax,%rbx)", potentially
making more efficient use of registers.  In the cases at hand, no such
sharing is possible since the addresses involved are entirely unrelated.

After this change, the code somewhat rudely accesses memory without
using a corresponding memory operand, which in some cases can lead to
unwanted "optimisations" of surrounding code.  However, the original
code also accesses memory not covered by a memory operand, so this is
not adding any defect not already present.  It is also hightly unlikely
that any such optimisations could be performed here since the memory
locations in questions are not accessed elsewhere in the same functions.

This fixes crashes with suncc.
Signed-off-by: Mans Rullgard <mans@mansr.com>

This code has been disabled since 2003.  Nobody will ever look at
it again.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Refactoring mmx2/mmxext YASM code with cpuflags will force renames.
So switching to a consistent naming scheme beforehand is sensible.
The name "mmxext" is more official and widespread and also the name
of the CPU flag, as reported e.g. by the Linux kernel.

register starvation caused gcc4.2 to fail building 32 bit shared libs
on 64 bit OS X
Signed-off-by: Michael Bradshaw <mbradshaw@sorensonmedia.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>