Created attachment 28411 [details] Compiler output I am using AVR-GCC to write some very low power RTC related code. The interrupt "ISR(RTC_OVF_vect)" executes faster with -Os optimization than it does with -O1, -O2 or -O3. I have measured execution time on an oscilloscope to confirm. V4.3.3 is the one that comes with Atmel Studio / WinAVR. Command line: avr-gcc -funsigned-char -funsigned-bitfields -DF_CPU=8000000UL -O3 -fpack-struct -fshort-enums -g2 -Wall -c -std=gnu99 -MD -MP -MF "rtc.d" -MT"rtc.d" -MT"rtc.o" -mmcu=atxmega128d3 -o"rtc.o" ".././rtc.c" I don't get any warnings etc. when compiling. Build machine is Windows 7 x64. Target is an XMEGA128D3, same issue confirmed with the 128A3U (unsurprisingly). The problem appears to be with GCC, rather than avr-libc, but please correct me if I am wrong.
Created attachment 28412 [details] Compiler output with -O3
atxmega128d3 is not supported by avr-gcc, neither in 4.3 nor in 4.4 nor 4.5 nor 4.6. Please report to the respective bug tracker, obviously some private toolchain port. Compiling with a current compiler that supports ATxmega128D3 (4.7 or newer) stops compilation with errors. And I actually don't understand teh issue: Optimizing for size does not require to produce slow code. The code may run fast. If your program relies on slow executable code, the program is incorrect.
(In reply to comment #2) > And I actually don't understand teh issue: Optimizing for size does not require > to produce slow code. The code may run fast. -O3 is supposed to produce the fastest possible code, but it doesn't. -Os is faster. At the very least the two should be equal. In other words -O3 is broken.
(In reply to comment #3) > (In reply to comment #2) > > > And I actually don't understand teh issue: Optimizing for size does not require > > to produce slow code. The code may run fast. > > -O3 is supposed to produce the fastest possible code, but it doesn't. -Os is > faster. At the very least the two should be equal. Supposed to? Where in the documentation is that specified? I remember a sentence that -O3 enables optimization that might not always be profitable (but that sentence seems to be gone from latest docs). > In other words -O3 is broken. It's behavior is certainly undesirable, but broken? For certain targets -Os might be a win because that's what it is tuned for or icache behavior is simply more important than anything else.
As a start, you could try to enable us to reproduce your problem. First of all, it is clear that we don't have your hardware (oscilloscope) to measure things and even if, it is very unlikely someone will start research to find out exactly were you lost the ticks. Second, notice that it is ulikely anybody is inclined to pick up buch of code you dumped above. It's 3800 lines and around 30 functions. And it fails to compile. Maybe you can be more descriptive and point out what /exactly/ goes wrong and work out a small example and limit to a critical spot or function and throw away unneeded stuff. Third, please notice that 4.3 is no more supported since several years now. Please supply code that compiles with a supported version of the compiler which implies at least 4.7 (because you use -mmcu=atxmega128d3). Fourth, you use inline assembler that is not correct because of missing memory barrier and might show malfunction in corner cases. Thus, you may want to fix at least 3. and 4. and rerun your benchmarks to see if the problem still exists. Very likely, that is not the case.
Closed as invalid. No answer and no valid test case for over 3 months now.