Instead of defining functions in per-arch header files included
by the main cpu.c, define them normally and call them from the
generic one.
Originally committed as revision 25084 to svn://svn.ffmpeg.org/ffmpeg/trunk
mm_support() instead.
Reduce complexity and simplify pending move to libavutil.
Originally committed as revision 25074 to svn://svn.ffmpeg.org/ffmpeg/trunk
Passing an explicit filename to this command is only necessary if the
documentation in the @file block refers to a file different from the
one the block resides in.
Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
This fixes a compilation issue on OS X 10.4, where some system headers were
included implicitly through dsputil_altivec.h (with _POSIX_C_SOURCE defined),
and other system headers included later, with _POSIX_C_SOURCE undefined at
that time.
Originally committed as revision 22327 to svn://svn.ffmpeg.org/ffmpeg/trunk
Otherwise doxygen complains about ambiguous filenames when files exist
under the same name in different subdirectories.
Originally committed as revision 16912 to svn://svn.ffmpeg.org/ffmpeg/trunk
Neither the asm() nor the __asm__() keyword is part of the C99
standard, but while GCC accepts the former in C89 syntax, it is not
accepted in C99 unless GNU extensions are turned on (with -fasm). The
latter form is accepted in any syntax as an extension (without
requiring further command-line options).
Sun Studio C99 compiler also does not accept asm() while accepting
__asm__(), albeit reporting warnings that it's not valid C99 syntax.
Originally committed as revision 15627 to svn://svn.ffmpeg.org/ffmpeg/trunk
similar typedefs that sysctl.h needs. Since sysctl() itself isn't POSIX
undefining _POSIX_C_SOURCE for check_altivec.c seems the best way to fix this.
patch by David Conrad lessen42 at gmail com
Originally committed as revision 15306 to svn://svn.ffmpeg.org/ffmpeg/trunk
Currently not enabled in FFmpeg, because it crashes if the OS does not
emulate mfspr.
Originally committed as revision 11569 to svn://svn.ffmpeg.org/ffmpeg/trunk
in a library.
Should not change anything for PPC, the autodetection is currently pointless due
to other code being compiled with -maltivec as well (and detection for OSX and
AmigaOS remains in place).
SPARC binaries built with VIS support can now only run on systems with VIS.
Originally committed as revision 10648 to svn://svn.ffmpeg.org/ffmpeg/trunk