1. 23 Jan, 2013 3 commits
  2. 22 Jan, 2013 3 commits
  3. 21 Jan, 2013 1 commit
  4. 20 Jan, 2013 2 commits
  5. 18 Jan, 2013 1 commit
  6. 16 Jan, 2013 1 commit
  7. 20 Dec, 2012 1 commit
  8. 26 Nov, 2012 1 commit
  9. 25 Nov, 2012 2 commits
  10. 16 Nov, 2012 1 commit
  11. 13 Nov, 2012 1 commit
  12. 31 Oct, 2012 3 commits
  13. 30 Oct, 2012 1 commit
  14. 05 Oct, 2012 1 commit
  15. 13 Sep, 2012 1 commit
  16. 12 Sep, 2012 1 commit
  17. 11 Sep, 2012 1 commit
  18. 07 Sep, 2012 3 commits
  19. 06 Sep, 2012 1 commit
  20. 30 Aug, 2012 2 commits
  21. 28 Aug, 2012 1 commit
  22. 08 Aug, 2012 1 commit
  23. 07 Aug, 2012 1 commit
  24. 03 Aug, 2012 2 commits
    • 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
    • Diego Biurrun's avatar
      x86: Use consistent 3dnowext function and macro name suffixes · ca844b7b
      Diego Biurrun authored
      Currently there is a wild mix of 3dn2/3dnow2/3dnowext.  Switching to
      "3dnowext", which is a more common name of the CPU flag, as reported
      e.g. by the Linux kernel, unifies this.
      ca844b7b
  25. 02 Aug, 2012 1 commit
  26. 28 Jul, 2012 1 commit
  27. 25 Jul, 2012 2 commits
    • Ronald S. Bultje's avatar
      x86/dsputil: put inline asm under HAVE_INLINE_ASM. · 79195ce5
      Ronald S. Bultje authored
      
      
      This allows compiling with compilers that don't support gcc-style
      inline assembly.
      Signed-off-by: default avatarDerek Buitenhuis <derek.buitenhuis@gmail.com>
      79195ce5
    • Yang Wang's avatar
      dsputil_mmx: fix incorrect assembly code · 845e92fd
      Yang Wang authored
      
      
      In ff_put_pixels_clamped_mmx(), there are two assembly code blocks.
      In the first block (in the unrolled loop), the instructions
      "movq 8%3, %%mm1 \n\t", and so forth, have problems.
      
      From above instruction, it is clear what the programmer wants: a load from
      p + 8. But this assembly code doesn’t guarantee that. It only works if the
      compiler puts p in a register to produce an instruction like this:
      "movq 8(%edi), %mm1". During compiler optimization, it is possible that the
      compiler will be able to constant propagate into p. Suppose p = &x[10000].
      Then operand 3 can become 10000(%edi), where %edi holds &x. And the instruction
      becomes "movq 810000(%edx)". That is, it will stride by 810000 instead of 8.
      
      This will cause a segmentation fault.
      
      This error was fixed in the second block of the assembly code, but not in
      the unrolled loop.
      
      How to reproduce:
          This error is exposed when we build using Intel C++ Compiler, with
          IPO+PGO optimization enabled. Crashed when decoding an MJPEG video.
      Signed-off-by: default avatarMichael Niedermayer <michaelni@gmx.at>
      Signed-off-by: default avatarDerek Buitenhuis <derek.buitenhuis@gmail.com>
      845e92fd