Coefs between 4 and 15 mess up in this routine...still.
If you have someone to look at this, now's a good time.
The top level of this is from ippsQuantInv_AAC_32s_I.
_w7_ownsReqCore_AAC_I: : 00617C5D cmp ecx,4 00617C60 jge _w7_ownsReqCore_AAC_I+0B3h (617C6Bh) 00617C62 mov eax,dword ptr [esp+ecx*4+4] 00617C66 jmp _w7_ownsReqCore_AAC_I+1DAh (617D92h) 00617C6B cmp ecx,10h 00617C6E jge _w7_ownsReqCore_AAC_I+0CEh (617C86h) 00617C70 mov edx,dword ptr [esp+20h] 00617C74 mov eax,dword ptr [edx+ecx*4+647D80h] // coef=6: eax=0xCF73154 (ok) 00617C7B mov ecx,dword ptr [esp+1Ch] // this loads ecx as 0 (bzt) re:scale 00617C7F sar eax,cl // should be shift >> 32 (yup) 00617C81 jmp _w7_ownsReqCore_AAC_I+1DAh (617D92h) // so instead of 0 this gets CF73154
Same with the base (non-sse2) version. And as I understand the x86, a shift is limited to 31, so the 32 (if it were there) won't even have an effect. It will on some other CPUs:movr0, r0, lsr r1 with r1 = 0x20 will zero r0 on an ARM, for example. Anyway, the case of the coefs being 4 to 15, and very small scale (I suppose) is rare, but happens.
Message Edited by BJ2 on 05-22-200609:04 PM