[avr-gcc-list] binutils 2.22 blow up program size with -flto

[Volker Kuhlmann]

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.