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.
Frankly I do not know Cortex-M3 assembler too much.
Then, with all due respect, it's rather seriously doubtful you could reliably tell the difference between an actual compiler bug, faulty source code being exposed by a correct compiler, and plain ill-founded expectations. Observations in a debugger are hardly ever sufficient to claim a compiler bug.
Keil is an expensive commercial product and maintainers should develop it different way than GPL code.
You have no idea what you're talking about. You certainly have no knowledge whatsoever how Keil develops their code. Nor, it appears, about the GPL side of that equation.
Professional behaviour is required on both ends of the bug processing business. And frankly, publicly slandering another party's product with basically no evidence to back up that claim, like you came here to do, is pretty much the opposite of professional behaviour.
When I buy a car and it did accelerate slowly, it is up to service and not to me, to disaasembly motor unit.
It's still up to you to establish that that "slowly" is actually significanly slower than the car is specified to accelerate. Otherwise, the service shop will just bill you the costs for searching a non-existend problem.
But you will get better service from the garage if you can clearly demonstrate that it is due to a fault in the car, rather than your driving style!
I think you are confusing identifying a bug with fixing a bug.
Keil is an expensive commercial product and maintainers should develop it different way than GPL code. For such GPL code you must find a bug and send a patch to author.
"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."
So, it now looks like you are seeing at least two problems.
As has already been indicated, the fact that your code works with one compiler and not another does not necessarily mean that the new compiler has produced bad code. It could be that functions and data have been shuffled around such that where you might have been lucky with a bug before might now be showing up.
If it really is "basic C/C++ functionality what is not working", then it should be quite straightforward to look at the assembler and see what is going wrong and where.
The thing to keep in mind is that in a mature compiler, bugs are (fortunately) quite rare. It is statistically far more likely that problems will be in the code being passed through the compiler than in the compiler itself.
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.
That is clear enough. And that does not prove that the compiler is to blame - may be this wasn't stated clearly enough.
#"passed completely different pointer" #What do you mean by that?
When I debugged a code and I let Keil to show &c inside watching and I saw some address. When I have seen contents of "p" it was different address.
The "c" was not changed after returning, so it means that some different memory area has been rewritten.
I am using Keil from 4.10 and I have not observed this issue until 4.13.
View all questions in Keil forum