[Ffmpeg-devel] [MacIntel] Testers welcome!

[Marco Manfredini]

On Monday 14 August 2006 16:06, John Dalgliesh wrote:

> OK I think you are missing a couple of steps of explanation here. Why do
> you care about that variable? Or are you implying that because it has
> reclaimed the stack space originally intended for 'i', that's why the
> var-len array isn't 16-byte aligned - despite the optimiser's assumption?
> If so, then please say so explictly; it's not at all clear to me that this
> is the reasoning you're following.

I have a different strategy with optimiser bugs, that's all.
'i' doesn't affect the placement of the array. My reasoning was, that gdb had 
a debugging record for 'i' and told me that at the place of the fault, 'i' 
was located in %ecx. However %ecx contained (src+i) as far as I could see. If 
the compiler had removed 'i' then there shouldn't be a debugging record for 
it anymore. If stuff like that happens, I usually seek a way to impede that 
certain optimisation, by giving the /failing/ compiler new information, such 
that I can say "if APPLE_GCC_4_0_1 then keep(&i)". 

>
> > Potentially bad is, that both solutions force 'i' into memory after
> > declaration.
>
> Yes if it affects the optimisation of the routine I don't think it'll be
> acceptable.

I haven't checked this. The asm block in keep uses '&i' as 
input-only-no-memory-clobber, so the compiler can still assume, that 'i' is 
not aliased. And at the begin of the lift blocks, 'i' gets a known value. 

>
> My main question is: Did my workaround work for you? The code obviously
> already does not expect temp_buf to be aligned, that's why it calculates
> temp at some offset into temp_buf. If think if the reason for the problem
> is found and addressed, then a simple patch like that workaround would be
> accepted.

The workaround works perfectly.

>
> The approach should be to either reproduce the behaviour in a simpler test
> case, and figure out which compilers it breaks on, or find the gcc bug /
> patch / changelog entry where it is fixed. It doesn't happen for me with
> gcc4.0.3 on linux ... but there are too many variations there to say that
> it has been fixed by 4.0.3.

I've added a stock FSF 4.0.1 to my linux test pack. The error doesn't show up 
here - I think the Apple branch is sometimes a bit funny.

Marco