[FFmpeg-devel] Hacks on FATE

[Måns Rullgård]

Michael Kostylev <michael.kostylev at gmail.com> writes:

> On Thu Jun 18 11:34:53 2009
> M?ns Rullg?rd wrote:
>
>>> fix building with i386-*-gcc-3.3 -fPIC
>>>
>>> --- ffmpeg.orig/libavcodec/x86/cavsdsp_mmx.c
>>> +++ ffmpeg/libavcodec/x86/cavsdsp_mmx.c
>>> @@ -280,7 +280,7 @@
>>>          VOP(%%mm1, %%mm2, %%mm3, %%mm4, %%mm5, %%mm0, OP)\
>>>          \
>>>          : "+a"(src), "+c"(dst)\
>>> -        : "S"((x86_reg)srcStride), "r"((x86_reg)dstStride), "m"(ADD), "m"(MUL1), "m"(MUL2)\
>>> +        : "S"((x86_reg)srcStride), "rm"((x86_reg)dstStride), "m"(ADD), "m"(MUL1), "m"(MUL2)\
>>>          : "memory"\
>>>       );\
>>>       if(h==16){\
>>> @@ -295,7 +295,7 @@
>>>              VOP(%%mm3, %%mm4, %%mm5, %%mm0, %%mm1, %%mm2, OP)\
>>>              \
>>>             : "+a"(src), "+c"(dst)\
>>> -           : "S"((x86_reg)srcStride), "r"((x86_reg)dstStride), "m"(ADD),  "m"(MUL1), "m"(MUL2)\
>>> +           : "S"((x86_reg)srcStride), "rm"((x86_reg)dstStride), "m"(ADD),  "m"(MUL1), "m"(MUL2)\
>>>             : "memory"\
>>>          );\
>>>       }\
>> 
>> An 'm' constraint requires an lvalue operand (or ought to do (llvm
>> does)), which a cast expression is not.
>
> % grep 'm"((x86_reg' -r .
> ./libavcodec/x86/snowdsp_mmx.c:             "rm"((x86_reg)(src_x<<1)),"m"(obmc),"a"(block),"m"(b_h),"m"(src_stride):\
> ./libavcodec/x86/snowdsp_mmx.c:             "rm"((x86_reg)(src_x<<1)),"m"(obmc),"a"(block),"m"(b_h),"m"(src_stride):\

Those are wrong then.  Think about it for a moment.  A memory operand
is nothing but a region of memory *with a specific type*.  A *value*
can be converted to another type (implicitly or by a cast), but a
value *as stored* has a fixed type that cannot be altered.

Using cast expressions with the 'm' constraint is as wrong as code
like this:

  void foo(int *);
  char x;
  foo((int*)&x);

That gcc, perhaps by accident, allows such nonsense is no excuse for
writing code that way.

Would it be feasible to rewrite these problematic functions with yasm
instead, and avoid all these errors?

-- 
M?ns Rullg?rd
mans at mansr.com