AVR C Runtime Library - Bugs: bug #20092, AVR-GCC code size increase from...
You are not allowed to post comments on this tracker with your current authentication level.
bug #20092: AVR-GCC code size increase from 3.4.6 to 4.1.2
Submitter: | None | ||
Submitted: | Wed 06 Jun 2007 02:33:54 AM UTC | ||
Category: | None | Severity: | 3 - Normal |
Priority: | 3 - Low | Item Group: | None |
Status: | Invalid | Assigned to: | joerg_wunsch |
Percent Complete: | 0% | Originator Email: | -email is unavailable- |
Open/Closed: | Closed | Release: | None |
Fixed Release: | None |
Tue 23 Oct 2007 01:44:40 PM UTC, comment #1: |
Joerg Wunsch <joerg_wunsch> |
Wed 06 Jun 2007 02:33:54 AM UTC, original submission:
Additional code size introduced in AVR-GCC compiler 4.1.2 as packaged in WinAVR-20070525 and as compared to 3.4.6 packaged in WinAVR-20060421
|
Anonymous |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Follow 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-10-23 | joerg_wunsch | Status | None | Invalid | |
Assigned to | None | joerg_wunsch | |||
Open/Closed | Open | Closed | |||
2007-09-12 | arcanum | Priority | 5 - Normal | 3 - Low |
Powered by Savane 3.13-02a9.
Corresponding source code
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));
int
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.