Bug 50733 - avr-gcc 4.3.5 generates incorrect code when using PROGMEM macro
Summary: avr-gcc 4.3.5 generates incorrect code when using PROGMEM macro
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.3.5
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-14 19:52 UTC by Marcos Vicente Cruz
Modified: 2011-12-01 12:43 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Preprocessed file (8.08 KB, application/octet-stream)
2011-10-14 19:52 UTC, Marcos Vicente Cruz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos Vicente Cruz 2011-10-14 19:52:11 UTC
Created attachment 25505 [details]
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
Comment 1 Jan Waclawek 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
Comment 2 Marcos Vicente Cruz 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.
Comment 3 Eric Weddington 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).