[Top][All Lists]

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

[avr-libc-dev] [bug #20092] AVR-GCC code size increase from 3.4.6 to 4.1

From: Joerg Wunsch
Subject: [avr-libc-dev] [bug #20092] AVR-GCC code size increase from 3.4.6 to 4.1.2
Date: Tue, 23 Oct 2007 13:44:40 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417

Update of bug #20092 (project avr-libc):

                  Status:                    None => Invalid                
             Assigned to:                    None => joerg_wunsch           
             Open/Closed:                    Open => Closed                 


Follow-up Comment #1:

Except for perhaps the EEPROM code, avr-libc is entirely the
wrong addressee for this.  For the EEPROM code, we *might* be
the correct one to handle it, provided:

. we get more details (it's not even clear what `size' is
  meant below, the size of the hex file?, the number of ROM
  bytes? -- I cannot reproduce any of these figures, not
  even closely)

. it turns out the regression is actually within avr-libc's
  domain, e.g. in an assembly source file -- if the compiler
  compiles C code into less optimal assembly, this is nothing
  the avr-libc folks could fix

As for the compiler changes itself, the only thing I'm immediately
aware of is that main() is now treated as a normal function,
so it gets prologue/epilogue code.  This can be avoided by
declaring it `naked' first:

int main(void) __attribute__((naked));
main(void) {

(A more appropriate attribute is in the works, this will
be the equivalent of other compilers' __C_task keyword.)

If you've got more details, and clear sample code that
allows others to reproduce and identify the optimization
regression, please open a WinAVR bug report for this.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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