Hi all,
The ABORTFP problems we're having appear to be due to a compiler bug. Broken
loop optimisation, I think. Looking at the compiler output, we have
_calc_xmin:
pushl %ebp ; set up the stack frame, and save off a few registers
movl %esp,%ebp
subl $76,%esp
pushl %edi
pushl %esi
pushl %ebx
movl $0,-24(%ebp)
cmpl $0,_gf+124 ; check gf.ATHonly
je L249 ; skip ATHonly code
...
L249:
movl 16(%ebp),%eax ; set up loop counters
movl 84(%eax),%ecx
cmpl $11,%ecx
jg L267 ; jump ahead if no iterations to do
flds _masking_lower ; load masking_lower for no apparent reason
flds -8(%ebp) ; load crap from stack
fldl -16(%ebp) ; and some more
.p2align 4,,7
L269:
The values at -8(%ebp) and -16(%ebp) are never initialised. I don't know
what the compiler expects to find there. A similar problem occurs in the
second loop (for long blocks).
Here's a quick patch to work around it. (One hack for each loop).
RCS file: /cvsroot/lame/lame/quantize-pvt.c,v
retrieving revision 1.44
diff -r1.44 quantize-pvt.c
705a706,710
>
> /* quick workaround for strange fp errors */
> volatile FLOAT8 hack;
> volatile FLOAT8 *phack = &hack;
>
721a727
> *phack = 0;
746a753
> *phack = 0;
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )