Bug 737950

This is the upstream fix for this specific issue:

http://gcc.gnu.org/viewcvs?view=revision&revision=175810

Jan

Thanks.
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.
http://koji.fedoraproject.org/koji/taskinfo?taskID=3348762
http://koji.fedoraproject.org/koji/taskinfo?taskID=3348767

I have tested this in the following combination on Fedora 15, x86_64:

]# rpm -qa | grep avr
avr-binutils-2.21-2.fc15.x86_64
avr-gcc-c++-4.6.1-3.fc15.x86_64
avr-libc-1.7.1-1.fc15.noarch
avr-gcc-4.6.1-3.fc15.x86_64
avrdude-5.10-3.fc15.x86_64

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!

Jan

Thank you. Will commit ASAP, I am pretty busy ATM.

Thibault

This fix works for me too.  I used the avr-gcc-c++-4.6.1-3.fc15.x86_64 from koji.

Thanks. My laptop just died so I cannot commit right now. Sorry for the delay. I will close that bug ASAP...

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?

Thanks!

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
http://koji.fedoraproject.org/koji/taskinfo?taskID=3414188

avr-gcc f15
http://koji.fedoraproject.org/koji/taskinfo?taskID=3414214

Please ping me again if I am too slow :)
Thanks,

Thank you very much, Thibault!

avr-libc-1.7.1-1.fc15,avr-gcc-4.6.1-3.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/avr-libc-1.7.1-1.fc15,avr-gcc-4.6.1-3.fc15

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:
https://admin.fedoraproject.org/updates/FEDORA-2011-14454
then log in and leave karma (feedback).

*** Bug 746778 has been marked as a duplicate of this bug. ***

Thank you -- the packages in updates-testing fixed my issue.

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.

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
avr-gcc-4.6.2-1.fc16.x86_64
avr-gcc-c++-4.6.2-1.fc16.x86_64
avr-binutils-2.20-2.fc16.x86_64
avr-libc-1.7.1-2.fc16.noarch
avrdude-5.11-1.fc15.x86_64

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

Sorry for that, I assumed that it made its way to 4.6.2.
I will look into that soon.
Thanks.

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 = {
...
to
const uint8_t font_5x8[486] PROGMEM = {
...

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

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 *
to
const char * PROGMEM

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

http://lists.nongnu.org/archive/html/avr-libc-commit/2012-01/msg00006.html

Off-topic:
Thibault:
there is new avr-libc version, could you package it?

Yup, that's on my todo list. Thanks for the reminder!

Perhaps you could try that build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3709668

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

Michal, did you have a chance to try it ?

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).

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:

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

and

(const or not) prog_char ook[]="hello world";
to
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.

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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping