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
