Re: [avr-libc-dev] [bugs #11396] Large number jumps to hyperspace

[Russell Shaw]

Paul Schlie wrote:
> > It's a total pain trying to find tool bugs by looking at the
> > asm output in a simulator. I've been looking at:
> >
> > #include<inttypes.h>
> >
> > int
> > main(void)
> > {
> >     uint16_t baud=9600;
> >     uint16_t reg=16000000/(16*baud) - 1;
> >     return 0;
> > }
> >
> > using gcc flags to put out rtl code (it'll take me a while
> > to understand it).
>
>
> If it's of any help, the code as written shouldn't actually do anything,
> as it will be optimized away.

I've thought of that, but was going to deal with it when i get there (use -O0 
etc).

> If you want to force an expression to be
> evaluated as written although it's assigned value may not be used, designate
> all interesting variables as volatile for testing purposes.

I thought of that too, but without knowing what the compiler does internally,
i didn't want to perturb test cases too much.

> Also as a heads
> up, if baud has a known value, reg's will also be statically computed (i.e.
> at compile time), so don't expect to see anything other than it's
> pre-computed value being assigned.

It was a compile-time constant.

> Lastly, which is likely your problem, if
> baud is not known statically, reg will computed dynamically (assuming it's
> value is used), but 16000000 is a ~34 bit number, resulting in a 64-bit (DI
> mode) division if designated as a long long computation, but it's not clear
> to me that 64-bit arithmetic has ever properly worked for the avr target; or
> you should have seen a warning that value was too large an int literal,
> where the value would have been truncated to a 16-bit int value = 0x2400 =
> 9216, which divided by (16*baud), would result in 0 - 1, resulting in -1,
> which may have affected a conditional expression or hw timer somewhere else
> in your code or system, or something like that.

but 16e6 is ~24 bits;)