Hi Volker There are known issues with LTO and AVR, though unknown reasons why. For now I would suggest that you avoid that feature.
However, please file a bug report at the GCC Bugzilla database. That way we can keep track of the various LTO issues and eventually try to get them fixed. Thanks, Eric Weddington > -----Original Message----- > From: avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org [mailto:avr- > gcc-list-bounces+eric.weddington=atmel....@nongnu.org] On Behalf Of Volker > Kuhlmann > Sent: Saturday, July 28, 2012 9:44 PM > To: avr-gcc-list@nongnu.org > Subject: [avr-gcc-list] binutils 2.22 blow up program size with -flto > > I am finding that with binutils 2.22 and newer gcc the program size goes > through the roof: > > Tested with Seismograph 1.8.3, avr-libc 1.7.1 with progmem const patch, > binutils 2.22 or 2.19.1 (indicated by bin219), > avr-gcc flags (the nolto are missing -flto) > -mmcu=atmega328p -Os -ffunction-sections -fdata-sections -mrelax -flto > -g2 -gstabs -std=gnu++0x > > text data bss dec hex filename > 21156 752 967 22875 595b output/Seismograph-183-436.elf > 21156 752 967 22875 595b output/Seismograph-183-436-bin219.elf > > 22742 1008 960 24710 6086 output/Seismograph-183-463.elf > 20730 750 966 22446 57ae output/Seismograph-183-463-bin219.elf > 21088 750 967 22805 5915 output/Seismograph-183-463-nolto.elf > 21088 750 967 22805 5915 output/Seismograph-183-463-bin219-nolto.elf > > 22016 748 960 23724 5cac output/Seismograph-183-471.elf > 21144 746 966 22856 5948 output/Seismograph-183-471-bin219.elf > 21278 746 967 22991 59cf output/Seismograph-183-471-nolto.elf > 21278 746 967 22991 59cf output/Seismograph-183-471-bin219-nolto.elf > > What could be the reason for this? > gcc was recompiled for each binutils version. > > The other sad thing is that gcc 4.7.1 does not improve code size over > 4.3.6, and matches it only with binutils 2.19.1 and no LTO, otherwise > being significantly worse. That's rather unexpected. Why could this be? > > The combination of binutils 2.22, gcc 4.6.3 and LTO produces a broken > program - never mind that for now. It's also the largest code size ever. > > I'm still trying to get the optimum out of LTO, so far gcc 4.6.3 with > binutils 2.19.1 and LTO gets top by far. > > Any hints thanksfully received, > > Volker > > -- > Volker Kuhlmann is list0570 with the domain in header. > http://volker.dnsalias.net/ Please do not CC list postings to me. > > _______________________________________________ > AVR-GCC-list mailing list > AVR-GCC-list@nongnu.org > https://lists.nongnu.org/mailman/listinfo/avr-gcc-list _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
