[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Allocation sequence of eeprom variables

From: David Brown
Subject: Re: [avr-gcc-list] Allocation sequence of eeprom variables
Date: Tue, 21 Aug 2012 12:07:29 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0

On 21/08/2012 10:38, Juergen Harms wrote:
On 08/20/2012 10:10 PM, David Brown wrote:
Almost certainly, there is something wrong in your code, or in the way
you have declared your external data - the "-Wuninitialized" flag should
not give false positives as you describe.  (It can give false positives,
when you know yourself that all code paths that use the data have
initialised the variables but the compiler is unable to prove this.)

I got rid of most of the "-Wuninitialized" warnings by introducing
intermediate typedefs - for instance, replacing

extern    const double    sunrise_fact[] PROGMEM;
typedef double PROGMEM        prog_double;
extern    const prog_double    *sunrise_fact;

One single warning remains that I did not manage to suppress:

extern    const prog_int8_t max_module;

What is wrong with that? max_module is defined in another module and is
initialised to a very constant value. The warning message is given when
VersionPanel.c is compiled

VersionPanel.c: In function 'ShowCpuInfo':
VersionPanel.c:71:26: warning: uninitialized variable 'max_module' put
into program memory area [-Wuninitialized]

and the reference to max_module in ShowCpuInfo is:

     if ( x_value <= pgm_read_byte ( &max_module ) ) {

Any suggestions how to avoid this last warning - would be great if I get
back to a make listing without warnings.

The use of "prog_int8_t" and similar types is deprecated:


These types had "PROGMEM" attached the progmem attribute to the type, rather than the variable, and I believe that does not work any more (if it ever did).

I don't think you should be getting an "unintialised" warning for:

extern const int8_t maxModule PROGMEM;

On older versions of avr gcc, there were spurious warnings - but I believe these have been fixed now.

The workaround for the warnings is simply to omit the "PROGMEM" on the extern declarations - it doesn't do anything anyway.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]