Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
Weddington, Eric wrote: The main function should still be set up as a OS_main function, i.e. it doesn't return anywhere. From how I understand OS_main and from the sources, there is nothing that adds noreturn semantics to OS_main. It's the same as OS_task except that OS_main assumes that IRQs are off. In particular, OS_main functions will have an epilogue. Johann ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
-Original Message- From: Georg-Johann Lay [mailto:a...@gjlay.de] Sent: Monday, January 30, 2012 4:34 AM To: Weddington, Eric Cc: Bill Westfield; avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked. Weddington, Eric wrote: The main function should still be set up as a OS_main function, i.e. it doesn't return anywhere. From how I understand OS_main and from the sources, there is nothing that adds noreturn semantics to OS_main. It's the same as OS_task except that OS_main assumes that IRQs are off. In particular, OS_main functions will have an epilogue. Oh, my apologies then. It's been a while since I looked as OS_main and I mistakenly thought it did that. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
To condense and summarize: Problem: optiboot, a very small bootloader, grows signficantly in binary size when going from gcc 4.5.2 to gcc 4.5.3. This turns out to be because it misses code factoring optimizations in optiboot's main() function, which is declared with attribute naked to save space. The missing optimizations are tied to naked; in sample programs the optimizations re-appear when the naked attribute is not used. Root cause: PR42240 is a patch that specifically disables jump modification in Naked functions, because they can interfere with proper exit handling of naked functions in .init sections. The .init sections are one of the primary intended uses for naked, while making main() naked is not a recommended practice (and in fact caused/uncovered other bugs in the optiboot code.) Resolution: optiboot will use the OS_main attribute instead of naked. It doesn't disable the optimization, the resulting code is small enough, and the attribute is more exactly appropriate and correct as well. It was probably an oversight that OS_main wasn't used in the first place. Thanks to all who assisted, especially Herr Lay, who identified the root cause! BillW ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
William, Are there any reasons you haven't tried avr-gcc 4.6.2? It was said previously that there are many avr bug fixes in the gcc 4.6 version, and it's also the current gcc version with better optimisations than 4.3 (I haven't put much/any effort into 4.5). The gcc version used by Arduino is still 4.3.3, so if you upgrade, what's the reason for not upgrading properly? Volker -- Volker Kuhlmann 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
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
On Jan 27, 2012, at 9:36 AM, Georg-Johann Lay wrote: OS_main/OS_task won't have the problem, but such functions cannot be used in .initN, of course. Except in the case where the code is in .init9 with custom startup code. Which is exactly what optiboot is doing. Perfect. Problem explained, workaround exists. Solved! Using OS_main also causes the frame pointer to be set up, so while the code is a big bigger than it could be, it is at least correct. BillW ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
William Chops Westfield schrieb: To condense and summarize: Resolution: optiboot will use the OS_main attribute instead of naked. It doesn't disable the optimization, the resulting code is small enough, and the attribute is more exactly appropriate and correct as well. It was probably an oversight that OS_main wasn't used in the first place. OS_task and OS_main are loitering around in official GCC sources quite some time now, since October 2007 which is since 4.3.0. The documentation was added 4 years later (PR49824) and is online since 4.6.2. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
1. If you complain of missed optimisations, you should post the command line switches you have used, the -Ox switch at least. 2. Don't use the naked attribute if you don't understand its implications - here, main uses stack frame which has not been created due to naked; this might work only by coincidence (Y being set to a sane value in startup). 3. You should post the assembler output of compiler (which contains symbolic labels) or relevant portions of disassembled elf, rather than disassembled object with unresolved jump targets, which makes tracing the code difficult. 4. If you desire control over code size (and other aspects of the code too), resort to assembler. Jan Waclawek ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
On Jan 26, 2012, at 2:10 PM, Georg-Johann Lay wrote: I tested the code with avr-gcc 4.5 and command line options -Os -mmcu=atmega8 With the attributes, the object size is 54 bytes. Without the attributes the object size is 64 bytes. With 4.5.3 ? Whatever this issue is, it apparently snuck in between 4.5.2 and 4.5.3. (reports are that 4.5.2 produced smaller code than 4.3.2) Sorry for forgetting the commandline/etc in my report. I am using -Os, and compiling for m328p (I added conditionals so I can control from command line) I get: billw@VB-Ubuntu$ avr-gcc -ggdb -Os -c -mmcu=atmega328p -mshort-calls foo.c billw@VB-Ubuntu$ avr-size foo.o text data bss dec hex filename 640 0 64 40 foo.o billw@VB-Ubuntu$ avr-gcc -ggdb -Os -c -mmcu=atmega328p -mshort-calls -DNAKED foo.c billw@VB-Ubuntu$ avr-size foo.o text data bss dec hex filename 580 0 58 3a foo.o and more substantial diffs, including the following. naked deletes the prolog, but adds instructions in the body... -.LM7: +.LSM6: ldi r24,lo8(5) - rjmp .L8 + rcall putch + rjmp .L4 .L3: -.LM8: +.LSM7: cpi r24,lo8(-127) brne .L5 -.LM9: +.LSM8: ldi r24,lo8(4) - rjmp .L8 + rcall putch + rjmp .L4 .L5: -.LM10: +.LSM9: ldi r24,lo8(3) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
Johann: I could reproduce it with one of the 4.7 packages (an older one) you provided. --- Moreover, in 4.7 it also stores the variable to stack frame even without naked, so that could be called a missed optimisation/regression. --- As far as code ineffiency goes, while there is always a chance that investigating that some otherwise covered bug could be revealed, I would not put much effort in it - you are simply not supposed to use naked for C functions. --- Sligtly OT, but once you reacted: 4. If you desire control over code size (and other aspects of the code too), resort to assembler. There is always that. At the moment, optiboot is a shining example of how the C compiler can generate output almost as small as assembler, and suitable for bootloaders and such. I never use the usual (and IMHO wrong) argument that assembler produces *smaller* code. Please note my wording. Jan Waclawek ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
William Chops Westfield wrote: On Jan 26, 2012, at 2:10 PM, Georg-Johann Lay wrote: I tested the code with avr-gcc 4.5 and command line options -Os -mmcu=atmega8 With the attributes, the object size is 54 bytes. Without the attributes the object size is 64 bytes. 4.5.3 ? Whatever this issue is, it apparently snuck in between 4.5.2 and 4.5.3. The only remarkable difference between 4.5.2 and 4.5.3 is the fix of PR42240. Depending on what distribution you use, your distributor added more patches, so we don't know. and more substantial diffs, including the following. naked deletes the prolog, but adds instructions in the body... -.LM7: +.LSM6: ldi r24,lo8(5) - rjmp .L8 + rcall putch + rjmp .L4 .L3: -.LM8: +.LSM7: cpi r24,lo8(-127) brne .L5 -.LM9: +.LSM8: ldi r24,lo8(4) - rjmp .L8 + rcall putch + rjmp .L4 .L5: -.LM10: +.LSM9: ldi r24,lo8(3) Some of the diff noise is because of different debug symbols/labels; Hunans see more without -g because of reduces debug info noise. The other changes look reasonable with fix PR42240. You may also want to have a look at OS_task and OS_main function attributes. If an older toolchain works better for you, maybe you are fine with the older version. Johann ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
On Jan 26, 2012, at 2:10 PM, Georg-Johann Lay wrote: I tested the code with avr-gcc 4.5 and command line options -Os -mmcu=atmega8 With the attributes, the object size is 54 bytes. Without the attributes the object size is 64 bytes. 4.5.3 ? Whatever this issue is, it apparently snuck in between 4.5.2 and 4.5.3. (reports are that 4.5.2 produced smaller code than 4.3.2) Sorry for forgetting the commandline/etc in my report. I am using -Os, and compiling for m328p I get: billw@VB-Ubuntu$ avr-gcc -ggdb -Os -c -mmcu=atmega328p -mshort-calls foo.c billw@VB-Ubuntu$ avr-size foo.o textdata bss dec hex filename 64 0 0 64 40 foo.o billw@VB-Ubuntu$ avr-gcc -ggdb -Os -c -mmcu=atmega328p -mshort-calls -DNAKED foo.c billw@VB-Ubuntu$ avr-size foo.o textdata bss dec hex filename 58 0 0 58 3a foo.o and more substantial diffs, including the following. naked deletes the prolog, but adds instructions in the body... -.LM7: +.LSM6: ldi r24,lo8(5) - rjmp .L8 + rcall putch + rjmp .L4 .L3: -.LM8: +.LSM7: cpi r24,lo8(-127) brne .L5 -.LM9: +.LSM8: ldi r24,lo8(4) - rjmp .L8 + rcall putch + rjmp .L4 .L5: -.LM10: +.LSM9: ldi r24,lo8(3) foo.c Description: Binary data ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
On 27.01.2012 01:40, William Chops Westfield wrote: (reports are that 4.5.2 produced smaller code than 4.3.2) Hmmm... defiant joe [~/tmp]: avr-gcc -dumpversion 4.3.4 defiant joe [~/tmp]: avr-gcc -ggdb -Os -c -mmcu=atmega328p -mshort-calls foo.c defiant joe [~/tmp]: avr-size foo.o textdata bss dec hex filename 54 0 0 54 36 foo.o defiant joe [~/tmp]: avr-gcc -ggdb -Os -c -mmcu=atmega328p -mshort-calls -DNAKED foo.c defiant joe [~/tmp]: avr-size foo.o textdata bss dec hex filename 52 0 0 52 34 foo.o Best regards, Joe ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
William Chops Westfield wrote: Hi, don't forget to use reply to all or at least to CC the lists themselves. On Jan 27, 2012, at 3:23 AM, Georg-Johann Lay wrote: 4.5.3 ? Whatever this issue is, it apparently snuck in between 4.5.2 and 4.5.3. The only remarkable difference between 4.5.2 and 4.5.3 is the fix of PR42240. That looks exactly relevant. The patch implements target hook TARGET_CANNOT_MODIFY_JUMPS_P in order to inhibit post-reload bb reorder for naked functions. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240 It looks like the patch to prevent reordering of instructions past the epilogue of naked functions prevents such reordering for the entire naked function. Yes. Though I'm not sure I understand why the original complaint was considered a bug. They appear to have been counting on a naked C function to fall in at the top and fall out at the bottom, which seems like even more of an abuse of naked than I was using (though I guess allowing that behavior is useful, especially in init code.) Thanks! BillW Yes. The reason why naked is there is that code can be put into .initN section. The code there is just like you lined out: enter at top an exit at bottom because such functions are not called, they are just collected and put in the respective .init section, one after one, like a pile of code. Naked will work with assembler code, but people also write C code to live in .init (making assumptions like there won't be a frame needed etc.). This means that you run into considerable problems if an epilogue (there may be more than one) is in the middle of the function. PR42240 fixes this and tries to make as much code as possible work together with naked at the expense of some additional instructions. OS_main/OS_task won't have the problem, but such functions cannot be used in .initN, of course. Except in the case where the code is in .init9 with custom startup code. Johann ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
William \Chops\ Westfield wes...@mac.com wrote: int main(void) __attribute__ ((naked)) __attribute__ ((section (.init9))); Instead of trying to force main into being naked, I think it would be better to use the OS_main attribute. Btw., please subscribe to the list. You might miss replies otherwise. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
Jan Waclawek schrieb: Moreover, in 4.7 it also stores the variable to stack frame even without naked, so that could be called a missed optimisation/regression. Thanks for pointing this out. I was lost in all that optimization conversation and thought it was an optimization issue from the first post. There is nothing written like program crashes because non-existent frame used. So the very problem is that there is a frame needed and there is none because of naked. Well, that's a bug in the user code, not in the application: You must not assume that the C code need no frame, even if it is a reasonable assumption like here. However, the frame is really strange and my first suspect is the evildoer: -fcaller-saves. That option causes evil in some places, or let me put things the other way round: In some cases -fno-caller-saves can avoid harm like spill fails in presence of high register pressure, see PR50925. Johann ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
-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 Bill Westfield Sent: Friday, January 27, 2012 4:28 PM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3,re naked. Though I'm not sure I understand why the original complaint was considered a bug. They appear to have been counting on a naked C function to fall in at the top and fall out at the bottom, which seems like even more of an abuse of naked than I was using (though I guess allowing that behavior is useful, especially in init code.) Well, ideally, it should just be a non-main function that is set up as naked and placed in a .initN section. That means it doesn't have a function prologue and epilogue, i.e. it's not called from anywhere and doesn't return anywhere; it just runs in line, which is what you need to put C code in a .initN section. The main function should still be set up as a OS_main function, i.e. it doesn't return anywhere. Subtle differences. But I thought that all this was described in the avr-libc user manual (and/or GCC manual). If not, then maybe we need to add something to the avr-libc FAQ. Eric ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
To condense and summarize: Problem: optiboot, a very small bootloader, grows signficantly in binary size when going from gcc 4.5.2 to gcc 4.5.3. This turns out to be because it misses code factoring optimizations in optiboot's main() function, which is declared with attribute naked to save space. The missing optimizations are tied to naked; in sample programs the optimizations re-appear when the naked attribute is not used. Root cause: PR42240 is a patch that specifically disables jump modification in Naked functions, because they can interfere with proper exit handling of naked functions in .init sections. The .init sections are one of the primary intended uses for naked, while making main() naked is not a recommended practice (and in fact caused/uncovered other bugs in the optiboot code.) Resolution: optiboot will use the OS_main attribute instead of naked. It doesn't disable the optimization, the resulting code is small enough, and the attribute is more exactly appropriate and correct as well. It was probably an oversight that OS_main wasn't used in the first place. Thanks to all who assisted, especially Herr Lay, who identified the root cause! BillW ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
On Jan 27, 2012, at 12:38 PM, Joerg Wunsch wrote: please subscribe to the list. You might miss replies otherwise. I am subscribed (at gmail); I've just be replying with the wrong from address :-( BillW ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
How does it compile if you change the C code to this?: int main(void) __attribute__ ((naked)) __attribute__ ((section (.init9))); int main() { uint8_t ch; for (;;) { ch = getch(); if(ch == STK_GET_PARAMETER) { register uint8_t which = getch(); register uint8_t output = 0x03; verifySpace(); if (which == 0x82) { output = OPTIBOOT_MINVER; } else if (which == 0x81) { output = OPTIBOOT_MAJVER; } putch(output); } That should help make it somewhat immune to the vagaries of the optimizer, but also keep the generated code small. Let me know what you get. 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 William Chops Westfield Sent: Thursday, January 26, 2012 11:11 AM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3,re naked. A week or so ago I mentioned that avr-gcc 4.5.3 caused the optiboot bootloader (used by Arduino and etc) to grow 22 bytes (from 500 bytes to 522 bytes, pushing it over the size that it needs to be.) This took a while to track down, because it's weird. Apparently gcc is optimizing code differently depending on whether the function is defined as naked or not. Optiboot sets up main() as naked to save space, and the lost optimization is hurting it. I have a small test case (even smaller than optiboot :-) (files also attached. foo.c, foo-naked.S, foo-clothed.S) Consider: int main(void) __attribute__ ((naked)) __attribute__ ((section (.init9))); int main() { uint8_t ch; for (;;) { ch = getch(); if(ch == STK_GET_PARAMETER) { register uint8_t which = getch(); verifySpace(); if (which == 0x82) { putch(OPTIBOOT_MINVER); } else if (which == 0x81) { putch(OPTIBOOT_MAJVER); } else { putch(0x03); } } Without the extra attributes for main, the is optimized to fact out the call to putch(): /* * Send optiboot version as minor SW version */ putch(OPTIBOOT_MINVER); 1c: 85 e0 ldi r24, 0x05 ; 5 1e: 00 c0 rjmp.+0 ; 0x20 main+0x20 } else if (which == 0x81) { 20: 81 38 cpi r24, 0x81 ; 129 22: 01 f4 brne.+0 ; 0x24 main+0x24 putch(OPTIBOOT_MAJVER); 24: 84 e0 ldi r24, 0x04 ; 4 26: 00 c0 rjmp.+0 ; 0x28 main+0x28 } else { /* * GET PARAMETER returns a generic 0x03 reply for * other parameters - enough to keep Avrdude happy */ putch(0x03); 28: 83 e0 ldi r24, 0x03 ; 3 2a: 00 d0 rcall .+0 ; 0x2c main+0x2c 2c: 00 c0 rjmp.+0 ; 0x2e main+0x2e } } WITH the extra attributes, I get three separate rcall instructions: putch(OPTIBOOT_MINVER); 12: 85 e0 ldi r24, 0x05 ; 5 14: 00 d0 rcall .+0 ; 0x16 main+0x16 16: 00 c0 rjmp.+0 ; 0x18 main+0x18 } else if (which == 0x81) { 18: 81 38 cpi r24, 0x81 ; 129 1a: 01 f4 brne.+0 ; 0x1c main+0x1c putch(OPTIBOOT_MAJVER); 1c: 84 e0 ldi r24, 0x04 ; 4 1e: 00 d0 rcall .+0 ; 0x20 main+0x20 20: 00 c0 rjmp.+0 ; 0x22 main+0x22 } else { /* * GET PARAMETER returns a generic 0x03 reply for * other parameters - enough to keep Avrdude happy */ putch(0x03); 22: 83 e0 ldi r24, 0x03 ; 3 24: 00 d0 rcall .+0 ; 0x26 main+0x26 26: 00 c0 rjmp.+0 ; 0x28 main+0x28 } } Any thoughts as to what might be going on here? Thanks WestfW ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
William Chops Westfield schrieb: A week or so ago I mentioned that avr-gcc 4.5.3 caused the optiboot bootloader (used by Arduino and etc) to grow 22 bytes (from 500 bytes to 522 bytes, pushing it over the size that it needs to be.) Any thoughts as to what might be going on here? Thanks WestfW I tested the code with avr-gcc 4.5 and command line options -Os -mmcu=atmega8 With the attributes, the object size is 54 bytes. Without the attributes the object size is 64 bytes. If you get 500 bytes you should turn on optimization. The difference between 54 and 64 is because main's prologue is not void if it's not naked. Herer is a diff between the respective assembler files: __SP_L__ = 0x3d __tmp_reg__ = 0 __zero_reg__ = 1 - .section.init9,ax,@progbits + .text .globalmain .type main, @function main: -/* prologue: naked */ + push r29 + push r28 + push __tmp_reg__ + in r28,__SP_L__ + in r29,__SP_H__ +/* prologue: function */ /* frame size = 1 */ -/* stack size = 0 */ -.L__stack_usage = 0 +/* stack size = 3 */ +.L__stack_usage = 3 .L7: rcall getch cpi r24,lo8(24) So you see it's all about prologue and naked, the code is the same. Johann ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
How does it compile if you change the C code to this?: [manually factoring out the common code] Yes, that will fix this particularly obvious instance, but it looks like gcc is failing to factor out common code like this in less obvious places as well... (Hmm. It behaves differently (correctly!) with attribute OS_main instead of naked. That's also interesting.) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list