This is seen on the version of avr-gcc 4.3.3 that gets built by the script that comes with FemtoOS 0.88. I'm compiling like this: avr-gcc -mmcu=atmega128 -O0 small_preprocessed.c -o small.elf And observing the result of a run like this: java -server avrora.Main -platform=mica2 -simulation=sensor-network -monitors=break -colors=false -seconds=15 small.elf Of course you need Avrora installed to do this. The program computes a checksum over its globals before terminating, this is found in the Avrora output as: r30:r31 = 0x5DAD It can be seen that the checksum computed at -O0 is different from higher optimization levels, which give 0xDBFA. My belief is that the -O0 result is wrong, and here's why: deleting almost any line of code from the program causes it to have the same checksum at all optimization levels. To see this, delete for example the line "int16_t l_46 = 1;" in func_43(). This line obviously has no effect on the computation. This changes the checksum to 0xDBFA, which is in agreement with higher optimization levels. The test code is obviously nonsense. However, I cannot give a smaller testcase since deleting code makes the problem go away. My belief is that this problem in not the result of a stack overflow: my stack analysis tool estimates that maximum RAM usage (including stack) is 2496 bytes, leaving plenty of free space on the mega128. My believe is that this problem is no due to undefined behavior in the C code.
Created attachment 17326 [details] failure-inducing C program
Created attachment 17334 [details] failure-inducing C program
Created attachment 17335 [details] diff between broken and working assembly This is a diff between the attachment compiled at -O0 and the same program but with the declaration and initialization of l_46 commented out. The first problem (I claim) produces incorrect output, the second correct. So this diff has to show the problem. The change is to turn func_43() to this: int32_t func_43 (int64_t p_44) { int16_t l_45 = 1; //int16_t l_46 = 1; return l_45; }
We narrowed this down to a nasty Avrora bug. In the future we'll try to reproduce in AVR Studio before reporting.