[Simulavr-devel] [bug #35737] new awr-gcc is picky about depreciated constants

2013-05-20 Thread Klaus Rudolph
Update of bug #35737 (project simulavr): Status: Duplicate => Fixed ___ Follow-up Comment #7: actual HEAD compiles with gcc 4.7.2 and avr-libc 1.8 _

[Simulavr-devel] [bug #35737] new awr-gcc is picky about depreciated constants

2013-03-24 Thread Thomas K.
Update of bug #35737 (project simulavr): Status:None => Duplicate Open/Closed:Open => Closed Discussion Lock: Any => Locked _

[Simulavr-devel] [bug #35737] new awr-gcc is picky about depreciated constants

2012-03-12 Thread Michael Hennebry
Follow-up Comment #3, bug #35737 (project simulavr): prog_char is something else to get rid of. It's not supposed to work. That it does is a compiler bug. In avr-g++, it doesn't work. That libc has it was a poor choice that causes occasional discussion on avrfreaks, especially when someone tries t

[Simulavr-devel] [bug #35737] new awr-gcc is picky about depreciated constants

2012-03-12 Thread anonymous
Follow-up Comment #5, bug #35737 (project simulavr): Just two small additional notes: PROGMEM is defined in "avr/include/avr/pgmspace.h": #define __ATTR_PROGMEM__ __attribute__((__progmem__)) #define PROGMEM __ATTR_PROGMEM__ and "prog_char" you can still find in "avr/include/avr/pgmspace.h": typ

[Simulavr-devel] [bug #35737] new awr-gcc is picky about depreciated constants

2012-03-12 Thread anonymous
Follow-up Comment #4, bug #35737 (project simulavr): Note that I also fix "prog_char" in my changes. There is only one place in the "./examples/atmel_key/scancodes.h" file which needs to be fixed. I change: prog_char shifted[][2] into: char shifted[][2] PROGMEM where "PROGMEM" actually means "__a

[Simulavr-devel] [bug #35737] new awr-gcc is picky about depreciated constants

2012-03-12 Thread anonymous
Follow-up Comment #2, bug #35737 (project simulavr): Hi, I decided to add some small comments to my previous post. Most of the changes, that I do, are "self-explanatory". You will get an "error: attempt to use poisoned SOME_MAGIC_NAME" if you do not apply them. However, there are some changes in