[FFmpeg-devel] [PATCH] EA TGQ video fixes

[Reimar Döffinger]

On Thu, Apr 16, 2009 at 08:40:56PM +0200, Vitor Sessak wrote:
> Reimar D?ffinger wrote:
> > On Thu, Apr 16, 2009 at 07:46:38PM +0200, Vitor Sessak wrote:
> >> Reimar D?ffinger wrote:
> >>>>> -    DCTELEM block[6][64];
> >>>>> +    DECLARE_ALIGNED_8(DCTELEM, block[6][64]);
> >>>>>  
> >>>>>      mode = bytestream_get_byte((const uint8_t**)bs);
> >>>>>      if (mode>buf_end-*bs) {
> >>> Moving it into the context instead should be more reliable.
> >> Why?
> > 
> > Because you are declaring a stack variable as aligned which only works
> > up to the value that the stack is already aligned usually which in the
> > past on e.g. Windows usually meant it wouldn't be aligned.
> > The situation should be better now but I doubt it is flawless and I also
> > don't really see a point in keeping the variable on the stack anyway.
> 
> Ugh... Makes me wonder two things:
> 
> 1- Why nobody thought of the possibility of mixing ASM+C when writing 
> the C99 spec?

ASM is outside the scope of C, making the extensions work properly is
the job of whoever invents them.
Also there may just be too many people who still haven't learned that
compilers will always be crap and believe in intrinsics...

> 2- Why the heck GCC implement __attribute__ (aligned) without making it 
> work properly (or warning when it don't)?

Because it works fine (for our needs) as long as your main app is
compiled with gcc (and as usual hardly anyone really cares about Windows).
Also "fixing" it has several issues, at least the fixes they've come up
with so far, you can still do it properly if you write the whole
function in asm and lastly in most cases like in this one the only
reason why it is on the stack is because someone was lazy.