[Bug c/50733] New: avr-gcc 4.3.5 generates incorrect code when using PROGMEM macro

[Bug c/50733] New: avr-gcc 4.3.5 generates incorrect code when using PROGMEM macro

[marcos_vc at coel dot com.br]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50733

             Bug #: 50733
           Summary: avr-gcc 4.3.5 generates incorrect code when using
                    PROGMEM macro
    Classification: Unclassified
           Product: gcc
           Version: 4.3.5
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: marcos_vc@coel.com.br


Created attachment 25505
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25505
Preprocessed file

Hi,

     The compiler is generating incorrect code for the source code below, when
using the PROGMEM macro:

#include <avr/io.h>
#include <avr/pgmspace.h> // PROGMEM
#include <stdio.h>

static PROGMEM const char orig[6] = { 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff };
static char dest[6];

int main(void) {

    for(;;) {
        unsigned int loop;
        for (loop = 0; loop < sizeof(orig)/sizeof(orig[0]); loop++)
            dest[loop] = orig[loop];
    }
}

    I compiled using the folowing command line:

avr-gcc -I/usr/lib/gcc/avr/4.3.5/include -I/usr/lib/gcc/avr/4.3.5/include-fixed
-I/usr/lib/avr/include -Wall -g3 -gstabs -O0 -fpack-struct -fshort-enums
-std=gnu99 -funsigned-char -funsigned-bitfields -save-temps -Wall -Wextra
-fno-strict-aliasing -fwrapv -mmcu=atmega16 -DF_CPU=1000000UL test.c


    It should have a "lpm" instruction somewhere in the asm output. The result
is "orig" not being copied to "dest".
    The compiler generates correct code when the PROGMEM macro is removed but
it generates a copy of the constant in the SRAM which is undesirable because
I´m using large tables that fills up all the SRAM.

GCC version: 4.3.5
Host type: x86_64-linux-gnu (Ubuntu 11.04)
Target type: avr
Configure command line: ../src/configure -v --enable-languages=c,c++
--prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man
--bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared
--with-system-zlib --enable-long-long --enable-nls --without-included-gettext
--disable-checking --disable-libssp --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=avr

[Bug target/50733] avr-gcc 4.3.5 generates incorrect code when using PROGMEM macro

[wek at host dot sk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50733

Jan Waclawek <wek at host dot sk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wek at host dot sk

--- Comment #1 from Jan Waclawek <wek at host dot sk> 2011-10-19 11:01:13 UTC ---
You cannot access variables placed into FLASH using the PROGMEM macro simply by
their name as if they would be normal variables (which are located in RAM). You
have to use dedicated functions such as pgm_read_byte() prototyped in
<avr/pgmspace.h>

Please refer to the relevant portions of avr-libc user manual
http://www.nongnu.org/avr-libc/user-manual/pgmspace.html and/or the PROGMEM
tutorial on avrfreaks.net
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=38003&start=all&postdays=0&postorder=asc

[Bug target/50733] avr-gcc 4.3.5 generates incorrect code when using PROGMEM macro

[marcos_vc at coel dot com.br]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50733

--- Comment #2 from marcos_vc at coel dot com.br 2011-10-19 15:02:10 UTC ---
In that case avr-gcc should print an error/warning when one try to access
variables that way. I'm newbie for this specific target and this code compiles
without any error or warning.

[Bug target/50733] avr-gcc 4.3.5 generates incorrect code when using PROGMEM macro

[eric.weddington at atmel dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50733

Eric Weddington <eric.weddington at atmel dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |eric.weddington at atmel
                   |                            |dot com
         Resolution|                            |WONTFIX

--- Comment #3 from Eric Weddington <eric.weddington at atmel dot com> 2011-12-01 12:43:35 UTC ---
This issue should go away when address spaces are done for the avr target (in
future 4.7). The PROGMEM macro equates to a GCC attribute for that variable to
place that into the Flash (Program Memory). It is up to the user to know this
and to use the related macros in avr-libc to correctly retrieve the data from
Flash. The AVR is a Harvard architecture chip and until Address Spaces were
added to GCC it didn't have a good way of knowing these address spaces and able
to generate a warning.

I'm marking this bug as WONTFIX, but I suggest that the bug reporter add their
email address to the CC field of bug #49868 (address spaces on the avr).