[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] AVR GCC Version 3.3 20030421 - taget mega128

From: Bruce D. Lightner
Subject: Re: [avr-gcc-list] AVR GCC Version 3.3 20030421 - taget mega128
Date: Thu, 07 Aug 2003 15:18:30 -0700
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3.1) Gecko/20030425


> "Peter A. Zuur" <address@hidden> writes:
>>I have found a bug in the AVR-GCC compiler (target mega128)
>>when used >>with any other optimization level than -O0 .
>>The following function which updates a crc-8 with <octet>
>>always returns 0 when compiled with optimization switched on.
>>The reason for that is that the compiler erroneously optimizes
>>the <then> clause of the <if> statement out.
>>unsigned char crc8(unsigned char crc, unsigned char octet)
>>    unsigned char j, tmp;
>>    j= 0;
>>    while(j < 8)
>>    {
>>        tmp= crc ^ octet;
>>        if(tmp & 0x01)      // optimized out
>>        {
>>            crc^= 0x18;     // optimized out
>>            crc>>= 1;       // optimized out
>>            crc|= 0x80;     // optimized out
>>        }
>>        else
>>        {
>>            crc>>= 1;       // always executed
>>        }
>>        octet>>= 1;     // optimized out
>>        j++;
>>    }
>>    return(crc);
I have fixed this bug in mainline. It's not an AVR specific bug it was
a bug in combine.c.

Look at gcc-patches archive with the following mail header:
From: Denis Chertykov <address@hidden>
Subject: Again combiner bug and fix
To: address@hidden
Date: Fri, 11 Jul 2003 00:01:23 +0400

This helps make to sense of what we recently discovered with the ATmega162 with avr-gcc 3.3. I have confirmed that this same bug exists with the ATmega162 part when using "-Os" with the latest WinAVR release.

This is the release pointed to by the AVR Freaks Web site (i.e., under the AVR_GCC tab), provided by Eric Weddington:

   Win32 build of avr-gcc 3.3, [11.8M] Apr.23, 2003

This reports itself as "gcc version 3.3 20030421 (prerelease)".

This likely explains differing behavior we saw for a large application moved from and AT90S8515/ATmega8515 (under avr-gcc 2.95) to the ATmega162L. Lowering the gcc 3.3 optimization level causes the code to "balloon" in size, but seems to fix the weird behavior.

Therefore, it looks like Eric's very convenient WinAVR "single-download" release is now suspect. Eric, send me your address and pizza order and I'll arrange for delivery, if you'll fix it! :-)

Best regards,


 Bruce D. Lightner
 Lightner Engineering
 La Jolla, California
 Voice: +1-858-551-4011
 FAX: +1-858-551-0777
 Email: address@hidden
 URL: http://www.lightner.net/lightner/bruce/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]