1. 15 Oct, 2012 1 commit
    • Mans Rullgard's avatar
      swscale: try to use mmap only if available · 95cd815c
      Mans Rullgard authored
      Some systems, e.g. Minix, have sys/mman.h defining MAP_ANONYMOUS without
      providing (working) mmap and friends.  The mmx filter generation code
      checks only for MAP_ANONYMOUS, not for availability of mmap itself which
      leads to build errors on aforementioned systems.
      
      This changes the conditional compilation to use mmap only if all the
      required functions are available.
      Signed-off-by: 's avatarMans Rullgard <mans@mansr.com>
      95cd815c
  2. 12 Oct, 2012 2 commits
  3. 10 Oct, 2012 1 commit
  4. 08 Oct, 2012 1 commit
  5. 06 Oct, 2012 1 commit
  6. 05 Oct, 2012 1 commit
  7. 13 Sep, 2012 1 commit
  8. 08 Sep, 2012 2 commits
  9. 07 Sep, 2012 1 commit
  10. 04 Sep, 2012 3 commits
  11. 30 Aug, 2012 2 commits
  12. 28 Aug, 2012 2 commits
  13. 19 Aug, 2012 1 commit
  14. 15 Aug, 2012 1 commit
  15. 13 Aug, 2012 2 commits
    • Mans Rullgard's avatar
      x86: swscale: fix fragile memory accesses · 90540c2d
      Mans Rullgard authored
      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: 's avatarMans Rullgard <mans@mansr.com>
      90540c2d
    • Mans Rullgard's avatar
      x86: swscale: remove disabled code · 10b83cb6
      Mans Rullgard authored
      This code has been disabled since 2003.  Nobody will ever look at
      it again.
      Signed-off-by: 's avatarMans Rullgard <mans@mansr.com>
      10b83cb6
  16. 08 Aug, 2012 1 commit
  17. 03 Aug, 2012 1 commit
    • Diego Biurrun's avatar
      x86: build: replace mmx2 by mmxext · 239fdf1b
      Diego Biurrun authored
      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.
      239fdf1b
  18. 30 Jul, 2012 1 commit
  19. 23 Jul, 2012 1 commit
  20. 22 Jul, 2012 3 commits
  21. 21 Jul, 2012 1 commit
  22. 04 Jul, 2012 3 commits
  23. 20 Jun, 2012 2 commits
  24. 12 Jun, 2012 1 commit
  25. 07 May, 2012 1 commit
  26. 22 Apr, 2012 1 commit
  27. 14 Apr, 2012 2 commits