On Wed, May 23, 2007 at 06:46:45PM -0500, Jack O'Quin wrote:
> On 5/23/07, Fons Adriaensen <fons@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
