Re: [LAU] building a debian system for audio

From: Fons Adriaensen <fons@email-addr-hidden>
Date: Thu May 24 2007 - 15:48:28 EEST

On Wed, May 23, 2007 at 06:46:45PM -0500, Jack O'Quin wrote:

> On 5/23/07, Fons Adriaensen <fons@email-addr-hidden> wrote:

> >What is even more scary is this: adding a extra printf() _after_ all
> >the calculations and _after_ a number of other printf() that I have
> >been using to see what is happening is enough to remove the error -
> >it modifies the values printed by the previous printf()...
> >I'm now pretty sure this is the optimiser having an identity
> >crisis...
>
> Arrgh! Put it in a separate function to defeat the optimizer?

Yes, that works, even if inlined.

Meanwhile I've found out what happened. The problem was not with
the float to int conversion, but with the FP calculation itself.

In one case, an intermediate value was stored to memory and
re-used from the stored value. In the second the register value
was used. A FP register has higher precision than a 32-bit FP in
memory, so storing it to memory requires rounding. And rounding
can change even the integer part in some rare cases.

Having both a register and a memory copy of the same variable
can produce very strange results, e.g.

    float v;
       v = // some calculation
       printf ("v = %12.9lf %08x\n", v, *((int *)(&v)));

can print either

  v = 29.990000000 41efeb85

or

  v = 29.989999771 41efeb85

depending on the context.

In the second line printf() uses the register value for the first
field, in the first the one stored in the variable v. It just depends
on what the optimiser prefers. The hex format always uses the value
stored in v.

-- 
FA
Follie! Follie! Delirio vano è questo !
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
Received on Thu May 24 16:15:07 2007

This archive was generated by hypermail 2.1.8 : Thu May 24 2007 - 16:15:08 EEST