Not a bug. But worthy of consideration.
Flash/RAM situation is the same as with other constant data.
gcc does not understanding different address spaces and is thus not able to inherrently change addressing modes.
The workaround being llok at is the assocaited with the ability of compiler back end to recognise in all affected RTL instructions (lots) if the operands are uniquely constant (ie FLASH) and then use the right instructions (lpm etc). Currently this is a challenge and not fully resolved.
However, this case maybe easier as the jump table should only be relevant to one RTL instruction, and as far as I can see ALWAYS constant (flash). So it may well be possible to change code to always use flash based table (lpm etc) and get rid of RAM impact. (with the neccessary changes to the location of table)
From: E. Weddington <address@hidden>
Cc: address@hidden; Denis Chertykov <address@hidden>; Björn Haase <address@hidden>
Subject: Re: [avr-gcc-list] Growing .data section when compiling with GCC 4.0 instead of GCC 3.4.3
Dave Hylands wrote:
>Hi Eric,
>
> >
[Discussions about switch statements getting compiled into jump tables with the jump tables stored in RAM.]
>>I'm not sure that it is a bug, per se. It's known that some swtich
>>statements get compiled into tables which can increase the size of the code.
>> >>
>
>It's really an issue of whether the tables are stored in flash or in
>RAM. Actually, because they're in RAM, they take up space twice, once
>in flash (used to initialize the RAM) and once in RAM, where they're
>actually used.
>
> >
Sure. I don't know for sure, though, but I would guess that that section of the port hasn't really changed, so in essence it's not a bug. It's a mis-feature, so technically it would be an enhancement request. Somebody who is more familiar with the AVR port (see new additions to CC list) can perhaps comment.
Eric
_______________________________________________
AVR-GCC-list mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/avr-gcc-list