[FFmpeg-devel] Hacks on FATE

[Michael Niedermayer]

On Thu, Jun 18, 2009 at 08:01:07PM +0100, M?ns Rullg?rd wrote:
> 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);

no, its rather like
void foo(int *);
char x;
foo(&((int)x));

this is either a syntax error or the compiler can use a temporery int,
or the compiler can have an internal error and do something else.
if gcc can handle it and llvm can not, llvm is buggy as gcc asm is defined
by gcc (sadly as that may be)


> 
> 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?

It would also feasable to travel on a goat around the world to
wash your hands. Though just washing your hands without the other part
is likely simpler.

back to the topic, the src_x that are passed into the function should
likely be <<1 and of type x86_reg, that is for snowdsp_mmx 

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090618/00b51197/attachment.pgp>