(
Jump to the original submission)
Sat 29 Oct 2011 01:04:02 PM UTC, comment #7:
I wasn't suggesting someone else do the backport, but I was wondering about my chances of success with applying the same patch you made for 4.6.2 to 4.3.3. Recompiling the source rpm shouldn't be too much of an issue.
What is the reason people are not upgrading to 4.6? 4.4 and 4.5 are not recommended (http://www.arduino.cc/playground/Learning/Linux).
|
Sat 29 Oct 2011 11:44:38 AM UTC, comment #6:
> Backport the gcc fix :-)
> it looks like it could be quite a while before it becomes
> available by normal upgrade.
avr-gcc's PR34734 is fixed in 4.6.2 and GCC 4.6.2 is available, see http://gcc.gnu.org/gcc-4.6
Bugfixes in avr-gcc are not backported to all versions supported by GCC because of avr-gcc developer shortage. That is: Bugfixes are only backported from current development trunk (4.7 at the moment) to 4.6.
Even if there was a backport to 4.5, you would still have to get a 4.5.3 distribution or build it yourself, anyway, as it won't tunnel into your local installation by magic ;-)
|
Sat 29 Oct 2011 10:42:01 AM UTC, comment #5:
Thanks Jörg. Those warnings are getting quite irritating in eclipse when there are a lot of them!
My suggestion has one drawback: Specifying sections in local variables gives a warning too, so I'm not sure what to do. Backport the gcc fix :-) it looks like it could be quite a while before it becomes available by normal upgrade.
The alternative is to declare the progmem variable extern first and then define it, but that has the same local variable problem.
I don't see any point in changing the section name, looking at the linker script shows that pretty much as long as it start with .progmem it's much of a muchness. The only requirement is to separate variable that are const into a differently named section from those not const. No functional difference, it's only to avoid the linker error. Maybe there's another way, but I can't think of a way to deal with progmems declared in functions. :-(
|
Sat 29 Oct 2011 08:23:16 AM UTC, comment #4:
As it's a GCC bug which has already been fixed there, and it only
produces a warning, I somewhat hesitate to add hacks in avr-libc for
that.
Would there be any point in moving all PSTR data (independent of the
GCC version) to .progmem.data?
|
Sat 29 Oct 2011 04:36:20 AM UTC, comment #3:
May I suggest to change the definition of PROGMEM for the buggy gcc versions as per the attached patch?
See bug #34680 for PSTR()
(file #24236)
|
Sat 29 Oct 2011 01:06:21 AM UTC, comment #2:
The approach of redefining PROGMEM to
#define PROGMEM attribute(( section(".progmem.data") ))
works, but is sensitive to storage class specification.
gives
error: string2 causes a section type conflict
Program memory is read-only flash memory so not using const is a bug. Unfortunately it seems avr-libc is pretty buggy here...
|
Sun 07 Feb 2010 11:14:50 PM UTC, comment #1:
Sorry, this is not an avr-libc bug but a GCC one. It has
already been filed to GCC's bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34734
Until it's fixed, you have to just live with the warning.
|
Sun 07 Feb 2010 11:01:18 PM UTC, original submission:
warning: only initialized variables can be placed into program memory area
this seems to be a regressiong, because it happens with code, that compiled about a year ago (no idea which version, maybe ~2007) without these warnings.
this was discussed in the ML 2009/12: http://lists.gnu.org/archive/html/avr-gcc-list/2009-12/msg00016.html
locally redefining...
#undef PROGMEM
#define PROGMEM _attribute_(( section(".progmem.data") ))
#undef PSTR
#define PSTR(s) (_extension_({static prog_char __c[] PROGMEM = (s); &__c[0];}))
... seems to fix it.
what's the "correct" approach to handle this?
|
(Note: upload size limit is set to 16384 kB, after insertion of the required
escape characters.)
Attach File(s):
Comment:
Depends on the following items: None found
Items that depend on this one: None found
Follow 4 latest changes.