[avr-gcc-list] I Think This Is A Bug

[David Kelly]

Avr-gcc doesn't doesn't fully evaluate this expression which should
reduce to 113. The FreeBSD version of gcc has no problem, but both the
FreeBSD ports version of avr-gcc and current WinAVR avr-gcc behave
identially (wrongly) the same:

unsigned long ulval;
unsigned char ucval;

junk()
{
        ucval = (1+(7372800L/(256*256)));
        ulval = (1+(7372800L/(256*256)));
}

On exit ulval contains 7372801 and ucval contains 0x01 when the correct
answer is 113. At least it spit out a bunch of warnings before I had to
find out the hard way.

% avr-gcc -O -gdwarf-2 -Wall -ffreestanding -mmcu=atmega128 -c junk.c
junk.c:5: warning: return type defaults to `int'
junk.c: In function `junk':
junk.c:6: warning: integer overflow in expression
junk.c:6: warning: integer overflow in expression
junk.c:6: warning: large integer implicitly truncated to unsigned type
junk.c:7: warning: integer overflow in expression
junk.c:7: warning: integer overflow in expression
junk.c:8: warning: control reaches end of non-void function
% avr-objdump -S junk.o

junk.o:     file format elf32-avr

Disassembly of section .text:

00000000 <junk>:
unsigned char ucval;

junk()
{
        ucval = (1+(7372800L/(256*256)));
   0:   81 e0           ldi     r24, 0x01       ; 1
   2:   80 93 00 00     sts     0x0000, r24
        ulval = (1+(7372800L/(256*256)));
   6:   81 e0           ldi     r24, 0x01       ; 1
   8:   90 e8           ldi     r25, 0x80       ; 128
   a:   a0 e7           ldi     r26, 0x70       ; 112
   c:   b0 e0           ldi     r27, 0x00       ; 0
   e:   80 93 00 00     sts     0x0000, r24
  12:   90 93 00 00     sts     0x0000, r25
  16:   a0 93 00 00     sts     0x0000, r26
  1a:   b0 93 00 00     sts     0x0000, r27
  1e:   08 95           ret
% avr-gcc --version
avr-gcc (GCC) 3.4.3
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.
%

Thought about posting this in Bugzilla but got confused with the fields
in the form. Will formally post it there if someone can confirm I'm not
losing my mind, that this really is a bug.

Also searching the buglist didn't turn up anything similar.

Hard coding the value to 113 gets me thru the day but has me searching
elsewhere for similar constants not being calculated correctly.

--
David Kelly N4HHE, address@hidden
========================================================================
Whom computers would destroy, they must first drive mad.

--
David Kelly N4HHE, address@hidden
========================================================================
Whom computers would destroy, they must first drive mad.