Bug 737950 - Bug in avr-g++ - wrong use of PROGMEM - fixed upstream
Summary: Bug in avr-g++ - wrong use of PROGMEM - fixed upstream
Alias: None
Product: Fedora
Classification: Fedora
Component: avr-gcc
Version: 15
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Thibault North
QA Contact: Fedora Extras Quality Assurance
: 746778 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-13 13:19 UTC by Jan Wildeboer
Modified: 2012-08-07 20:05 UTC (History)
9 users (show)

Fixed In Version: avr-libc-1.7.1-1.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-08-07 20:05:51 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 737449 None None None Never

Internal Links: 737449

Description Jan Wildeboer 2011-09-13 13:19:38 UTC
Description of problem:

See #737449 here for more background and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764 for upstream info

Version-Release number of selected component (if applicable):


How reproducible:

See upstream report

Steps to Reproduce:
1. See upstream report
Actual results:

Compile error

Expected results:

Compile works

Additional info:

Very simple test:

#include <avr/pgmspace.h>

int main(void)
  PGM_P p = PSTR("|<>^+=?/[];,*\"\\");
  return 0;

Take this code, save it as main.c and run it through avr-gcc:

avr-gcc -c -mmcu=atmega644p  main.c

... works.

Rename file to main.cpp and run it through avr-g++:

# avr-g++ -c -mmcu=atmega644p  main.cpp
main.cpp: In function 'int main()':
main.cpp:5:13: error: variable '__c' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
main.cpp:5:13: warning: only initialized variables can be placed into program memory area [enabled by default]


Comment 1 Jan Wildeboer 2011-09-13 15:40:27 UTC
This is the upstream fix for this specific issue:



Comment 2 Thibault North 2011-09-13 17:00:50 UTC
As I don't have a device to test it, here is a scratch build again, including your fix.
I will commit if it works for you.

Comment 3 Jan Wildeboer 2011-09-14 08:32:36 UTC
I have tested this in the following combination on Fedora 15, x86_64:

]# rpm -qa | grep avr

with my simple test code and the full Sprinter package.

It all works! So safe to commit from my side :-)

Thanks for the quick fix! I am really happy!


Comment 4 Thibault North 2011-09-20 14:35:09 UTC
Thank you. Will commit ASAP, I am pretty busy ATM.


Comment 5 Aidan Delaney 2011-09-21 19:42:09 UTC
This fix works for me too.  I used the avr-gcc-c++-4.6.1-3.fc15.x86_64 from koji.

Comment 6 Thibault North 2011-09-23 12:16:41 UTC
Thanks. My laptop just died so I cannot commit right now. Sorry for the delay. I will close that bug ASAP...

Comment 7 Erik Logtenberg 2011-10-08 18:44:03 UTC
Hi Thibault,

I am happy to read that your scratch build fixes the issue. However the rpm's are no longer available on koji, and I can't see any fedora release / testing / rawhide repo where the update is available.

Could you please either push it to a testing repo or at least make a second scratch build so I can download the rpm manually?


Comment 8 Thibault North 2011-10-08 19:30:18 UTC
Hi Erik,

I am _really_ sorry, I couldn't do it yet. Deadlines approaching, but I will do it next week-end hopefully. In the meantime, here are scratch builds again; my new laptop is now ready.

avr-libc f15

avr-gcc f15

Please ping me again if I am too slow :)

Comment 9 Erik Logtenberg 2011-10-09 12:25:23 UTC
Thank you very much, Thibault!

Comment 10 Fedora Update System 2011-10-15 21:35:41 UTC
avr-libc-1.7.1-1.fc15,avr-gcc-4.6.1-3.fc15 has been submitted as an update for Fedora 15.

Comment 11 Fedora Update System 2011-10-16 22:26:29 UTC
Package avr-libc-1.7.1-1.fc15, avr-gcc-4.6.1-3.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing avr-libc-1.7.1-1.fc15 avr-gcc-4.6.1-3.fc15'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 12 Peter Oliver 2011-10-17 18:50:54 UTC
*** Bug 746778 has been marked as a duplicate of this bug. ***

Comment 13 n02384301 2011-10-18 15:32:27 UTC
Thank you -- the packages in updates-testing fixed my issue.

Comment 14 Fedora Update System 2011-10-24 22:56:20 UTC
avr-libc-1.7.1-1.fc15, avr-gcc-4.6.1-3.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 Andrew Elwell 2012-01-11 08:45:11 UTC
I'm still seeing this on F16 with the following testcase:

$> cat testcase.cpp 
#include <avr/pgmspace.h>
int main(void)
  const void *x=PSTR("hello");
  static const char y[] PROGMEM ="foo";
  static char z[] PROGMEM ="bar";
  for(;x!=y && y[0] && z[0];); /* nothing, just make x,y,z used from gcc's
point of view */
  return 0;
$> avr-gcc -c -mmcu=atmega328p -Os -Wall testcase.cpp 
testcase.cpp: In function 'int main()':
testcase.cpp:7:46: error: variable 'z' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
$> rpm -qa | grep avr

Can this be repoened or would you like a new bug opened?

Comment 16 Thibault North 2012-01-11 13:34:36 UTC
Sorry for that, I assumed that it made its way to 4.6.2.
I will look into that soon.

Comment 17 Andrew Elwell 2012-01-11 18:49:41 UTC
Hmm - When I run the testcase to 4.6.1 its far worse, so it could be that this is the expected behaviour. I don't understand enough C++ to be able to say one way or the other :-/ 

However, by changing 
uint8_t font_5x8[486] PROGMEM = {
const uint8_t font_5x8[486] PROGMEM = {

I've got my code compiling and running. Excuse the noise.

Comment 18 Michal Hlavinka 2012-01-17 10:43:48 UTC
I guess this is intentional behaviour together with "broken" PROGMEM types in avr/pgmspace.h. New g++ does not preserver attributes on type definitions. They must be added to variable declarations now. See comment in new=1.8.0 pgmspace.h:

   This typedef is now deprecated because the usage of the __progmem__ 
   attribute on a type is not supported in GCC. However, the use of the 
   __progmem__ attribute on a variable declaration is supported, and this is 
   now the recommended usage.

Because g++ does not handle PROGMEM correctly (it's attribute in typedef, right?) avr-libc doped all prog_uchar and other prog_* variables (it won't work anyway). In new version you need to add #define __PROG_TYPES_COMPAT__ (before pgmspace include) if you want to compile your old code, other way you'll get lot of 

error: 'prog_char' does not name a type

Anyway, fast fix to get it compiled is that #define. The Right Way is to change (const or not) prog_char *
const char * PROGMEM

avr-libc added const everywhere and everyone should do it too.


there is new avr-libc version, could you package it?

Comment 19 Thibault North 2012-01-17 13:26:40 UTC
Yup, that's on my todo list. Thanks for the reminder!

Comment 20 Thibault North 2012-01-17 18:36:48 UTC
Perhaps you could try that build:

Due to a bug in doxygen, I compiled it only for f17, but the update may be backported to f16/f15 if necessary.

Comment 21 Thibault North 2012-02-14 18:05:28 UTC
Michal, did you have a chance to try it ?

Comment 22 Michal Hlavinka 2012-02-15 08:31:04 UTC
I tried avr-libc 1.8.0, but not that koji build exactly. 
I checked out avr-libc f16 branch, updated tarball to 1.8.0, removed PSTR patch and build it. I'm using it for a month now without any problem. Well, new version is not a 1:1 replacement - because gcc ignore attributes in typedefs, prog_* types are ordinary types ('prog_char' has exactly the same meaning as 'char'). PROGMEM must be specified on variable definition&initialization (this is how it's designed to work, nothing is going to change). Because of this, avr-libc removed prog_* types, so now you get "prog_* does not name a type" build error unless you define __PROG_TYPES_COMPAT__ (and you'll get deprecated warnings). So be ready to see a few scared people = bug reports (if they don't read changelog or google for that error).

Comment 24 Michal Hlavinka 2012-02-15 09:02:01 UTC
and one type correction again :) (I make prev. comment hidden, so it does not confuse people).
(In reply to comment #18)
> Anyway, fast fix to get it compiled is that #define. The Right Way is to change
> (const or not) prog_char *
> to
> const char * PROGMEM

Just for the record (for those who find this using google). The above is not
correct. It should be:

(const or not) prog_char *foo;
const char *foo;


(const or not) prog_char ook[]="hello world";
const char ook[] PROGMEM = "hello world";

PROGMEM should go only where data initialization is used, it does not affect
type, it affects the initialization data - where to put them.

Note: I use typedef char pm_char; it has no effect, just I can immediately see
that this variable works with progmem data.

Comment 25 Fedora End Of Life 2012-08-07 20:05:54 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:

Note You need to log in before you can comment on or make changes to this bug.