Re: [avr-gcc-list] Growing .data section when compiling with GCC 4.0 instead of GCC 3.4.3

[Bernard Fouché]

Bingo! I'm back to my usual .data size when I compile with -mno-tablejump.

Should I fill a bug report? Is this a bug anyway? I think so since I do 
not see why the array is built in ram, it should be in flash since all 
addresses are constants..

Now the win between gcc3.4.3 and gcc4.0.0 is much more smaller. Here are 
the application text sizes compiled with gcc-3.4.3 and gcc-4.0.0 
(ntj=compilation with -mno-tablejump)

gcc-3.4.3 ntj  |  gcc-3.4.3 | gcc-4.0.0 ntj | gcc-4.0.0
--------------------------------------------------------------
51364          |  50874     | 50588         | 49782(*)

(*) table jump uses 218 bytes of RAM.

Now 49782+218=50000, so the best would be with table jump in flash.

BTW I'm very far from the 8% I mentionned in a previous mail, I also had 
problems with an included lib (but on gcc3.4.3), now everything is clean 
and I'm sure of the values. So if ever gcc4.0.0 can make an application 
50000 bytes in size, compared to 50874, I would have win about 1% of 
code size. Which is still a win..

 Bernard

Thanks Dave for your help.

Dave Hylands wrote:

> On 4/27/05, Bernard Fouché <address@hidden> wrote:
>
> > Good hint Dave: of the 90 objects making the application, I find 2
> > objects having a big increase in .data . The 2 C files corresponding to
> > these objects both have a big switch/case and it seems that the compiler
> > is making some kind of 'jump table' to each 'case', probably to optimize
> > the speed of processing the switch/case.
>
> Try using the -mno-tablejump option to see if that helps.