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/ )

Reply via email to