There seem to be a severe ~20% code size regression on AVR target (atmega328p) in gcc 9.1.0. I'm building https://github.com/gnea/grbl, which need to fit in 32k. This used to work just fine (29786 bytes), but with 9.1.0 it is way over target size (35492 bytes). Compile options are the default '-Os -flto' on both. gcc 8.3.0 % avr-gcc --version avr-gcc (GCC) 8.3.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % avr-size grbl.hex text data bss dec hex filename 0 29786 0 29786 745a grbl.hex gcc 9.1.0: % avr-gcc --version avr-gcc (GCC) 9.1.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % avr-size grbl.hex text data bss dec hex filename 0 35492 0 35492 8aa4 grbl.hex
I can confirm a problem with gcc 9.1.0. I hit into it today when I tried compile DFU bootloder from LUFA project for atmega32u4. From some unknwon reason for me it compiles without any problem for atmega16u2. Compiling DFU bootloader for atmega32u4 and atmega16u2 works on gcc-8.3.0.
How did you conclude it's a target issue? Would you pinpoint where in the avr backend the problem is?
This is still an issue with gcc-9.2.0.
(In reply to Nicola Fontana from comment #3) > This is still an issue with gcc-9.2.0. We still have no test case.
I did a small research in this topic and now I know that avr-gcc-9.1.0 compiler generates some additional, overhead operations, like: 932: 6e 87 std Y+14, r22 ; 0x0e 934: 7f 87 std Y+15, r23 ; 0x0f 936: 88 8b std Y+16, r24 ; 0x10 938: 99 8b std Y+17, r25 ; 0x11 93a: 6e 85 ldd r22, Y+14 ; 0x0e 93c: 7f 85 ldd r23, Y+15 ; 0x0f 93e: 88 89 ldd r24, Y+16 ; 0x10 940: 99 89 ldd r25, Y+17 ; 0x11 Storing and reading back the same registers. I just found that exactly the same case is already reported with issue id 90706. Because of this I will not attach any examples here. In my opinion the current issue depends on 90706 (please somebody update the 'Depends on' field of the issue). When 90706 is fixed then we should recheck this again and we will se how much it improves the situation.
*** This bug has been marked as a duplicate of bug 90706 ***