[FFmpeg-cvslog] r21069 - trunk/libavcodec/alsdec.c

[Uoti Urpala]

On Sat, 2010-01-09 at 12:40 +0100, Thilo Borgmann wrote:
> >        for (sb = -opt_order; sb < 0; sb++)
> >            y += MUL64(lpc_cof[sb], raw_samples[sb]);

Here opt_order is unsigned int and sb is a signed int. Assuming the
original value is a smallish number, "-opt_order" will be a large
positive number but casting it to signed int should give the intended
result (the large positive value will not be representable as int;
converting a value to a signed type when the value can not be
represented in that type is implementation-defined behavior, but gcc
defines it to work as expected).

> does not work in gcc 4.1.x if opt_order is an unsigned int.
> Debug output showed that the loop is not executed even once then (so I
> think sb got a big positive number assigned). A quick test worked with:

I doubt your "big positive number" assumption is correct. The original
big positive number cannot possibly be assigned to the signed variable,
as there is no way to represent it in the type of the variable.
Assigning some _other_ slightly less big number seems unlikely.

My guess is that there's a bug in the 4.1.x optimizer that makes it
assume "sb = non_negative_number" results in sb being nonnegative
(ignoring the fact that casting to signed can result in a negative
number when an out-of-range value is reduced), and the optimizer
therefore incorrectly removes the whole loop.

> 
> >        for (sb = -(int)(opt_order); ...)
> 
> so the local opt_order variable has been changed to int now.
> Thus, using "-a" is not a good idea if a is unsigned. At least for gcc
> 4.1.x.

"-a" should be safe. The problematic part is almost certainly the cast
from unsigned to signed when the unsigned result is assigned to the
signed variable sb.