Someone recently suggested (on the linked Arduino conversation) that this could be due to the "undefined" nature of infinite loops? Indeed, putting an volatile access or replacing the final "while(1);" loop with an abort() causes the symptom to go away. Any of the OMITBUGx defines will make it work.
#include <avr/io.h> #include <stdlib.h> void serialEvent() __attribute__((weak)); void loop(); void serialEventRun(void) { #ifndef OMITBUG if (serialEvent) serialEvent(); #endif } #ifdef OMITBUG2 void serialEvent() { } #endif int main() { for (;;) { loop(); if (serialEventRun) serialEventRun(); } } int nnn = 1; void loop() { if (nnn <= 3) { char rrr = 0; while ( !rrr ) { if (PORTB) rrr = (PORTB == 'c' ); } PORTB |= 1 << 5; nnn++; } else #ifdef OMITBUG4 abort(); #else while (1) #ifndef OMITBUG3 ; #else PORTB = 1; #endif #endif } On Fri, Jul 6, 2018 at 6:10 PM, Bill Westfield <wes...@gmail.com> wrote: > Discovered on Arduino (4.9.2-atmel3.5.4) ( http://forum.arduino.cc/index. > php?topic=556674.0 ) > So I have this pretty trivial avr-gcc program: > > #include <avr/io.h> > > void serialEvent() __attribute__((weak)); > void loop(); > > void serialEventRun(void) > { > #ifndef OMITBUG > if (serialEvent) serialEvent(); > #endif > } > > int main() { > for (;;) { > loop(); > if (serialEventRun) serialEventRun(); > } > } > > int nnn = 1; > > void loop() > { > if (nnn <= 3) { > char rrr = 0; > while ( !rrr ) { > if (PORTB) > rrr = (PORTB == 'c' ); > } > PORTB |= 1 << 5; > nnn++; > } else while (1); > } > > If compile with "avr-gcc -g -Os -flto -mmcu=atmega328p bug.c -o bug.elf" > it will produce code that omits the test for (nnn <= 3) > Turning off -flto, or adding -DOMITBUG to the compile line (removing the > call to the non-existent serialEvent() function) results in correct code. > > Discovered on Arduino (4.9.2-atmel3.5.4) ( http://forum.arduino.cc/index. > php?topic=556674.0 ) > > Also fails with avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_496) 5.4.0 and > avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_1750) 5.4.0 > With avr-gcc 8.1, it produce an additional error that may or may not be > relevant: > > C:\Users\billw\Documents\src>\bin\avr-gcc-8.1.0-x86-mingw\bin\avr-gcc -g > -Os -flto -mmcu=atmega328p bug.c -o bug.elf > C:\Users\billw\AppData\Local\Temp\ccE52smMdebugobjtem: file not > recognized: File truncated > collect2.exe: error: ld returned 1 exit status > lto-wrapper.exe: fatal error: \bin\avr-gcc-8.1.0-x86-mingw\bin\avr-gcc > returned 1 exit status > compilation terminated. > c:/bin/avr-gcc-8.1.0-x86-mingw/bin/../lib/gcc/avr/8.1.0/../../../../avr/bin/ld.exe: > error: lto-wrapper failed > collect2.exe: error: ld returned 1 exit status > > (8.1 files in ld even with -DOMITBUG, though slightly differenty. It > works without -flto) > > Um. Wild guess: The if (serialEvent) serialEvent(); line generates > slightly odd code, including a call to an absolute address of 0x0. > Is there something in link that uses a 0x0 address as an "end of list" > indicator? > ba: 20 97 sbiw r28, 0x00 ; 0 > bc: 71 f3 breq .-36 ; 0x9a <main+0x4> > be: 0e 94 00 00 call 0 ; 0x0 <__vectors> > > > -save-temp data attached for both working and fail cases. > >
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list