I warn anybody before using ARM Keil 4.13a. It generates defective code. I have spent several hours with debugging a code that has been already worked. The problem affects local variables of functions and passing arguments. Code has been wrongly compiled without any optimization. I have no courage and time to test optimizations.
I also encourage Keil not to publish Keil 4.13a any more.
Keil 4.12 seems to be OK.
The only issue I have found, created a snapshot of, and reported to keil is the debugger reporting the wrong value of automatic variables. It is not easy to reproduce - changing one line of code will correct it! However, I did manage to reproduce a serious failure of the tool chain and and posted it to keil but they somehow failed to get it to run on an evaluation board (I need to do it myself). A function, not being called at all from anywhere in the software, will cause a controller "abort" upon startup. But when the function is removed - again, it has no side effects - the controller will startup correctly. I will try to reproduce it this week - the code is attached to a Keil case.
If you look at linked image, you could see two objects ss and ssss. Object ss is an automatic object, and it was not initialized properly.
It is very hard for me to prepare test-case snapshot that reproduces Keil bug from two reasons: A, I cannot send our proprietary code, so I have to write different code that triggers a bug. B, My manager expects me to work and not to debug a Keil.
But anyway, I will look at this issue deeper when Keil hotline answers me something.
"I have spent several hours with debugging a code ..."
Do you think several hours is enough to spend on a problem that is as important as you suggest?
Did you step through the assembler for the function in question to verify what was really happening?
You may be right when you say "it produces defective code", but it might be better for both you and Keil to get as much concrete evidence as possible for Keil to examine. I also have proprietary code, but I managed to narrow it down to just 4 lines of (faulty) assembler that was being generated from 30 lines of C source. When I handed it to Keil I was as sure as I could be that I had actually found a genuine, reproducable problem.
Hi guys, the source code mentioned by Jaroslav works flawlessly when compiled by V 4.12, but binary compiled by V 4.13a is really defective - may be Jaroslav did not emphasize this clearly enough. So it apparently is not a bug in source code. It's really a basic C/C++ functionality what is not working - for example locally declared object in a method of some other class does not properly execute it's constructor - and thus is not initialize at all. Also parameters are not correctly passed to a functions. I'm a colleague of Jaroslav - I've seen this issues with my own eyes...
Bottom line: May be .13 in the version number is not happy enough number ;-)