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.
#"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.
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.
"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.
Frankly I do not know Cortex-M3 assembler too much.
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.
When I buy a car and it did accelerate slowly, it is up to service and not to me, to disaasembly motor unit.
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.
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.
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.
This post has been primarily intended only to warn user, not for analysing Keil failures.
It is true that Keil debugger sometimes lies. When you insert into code printf("",...), you have to see real content of a variable neglecting Keil debugger. If not, there is something wrong. Printf has nothing to do with debugger and it displays real variables (I have configured it to serial line).
May be that adding several lines into code would hide a bug observed, may be not.
This post has been primarily intended only to warn user,
But you're not in any position to publish such a warning. You have neither the factual evidence nor the community standing to back up your claims.
In fact just about the only thing preventing your presentation here from being a suable act of slander is its rather obvious lack of credibility.
Hans-Bernhard,
You're being a a little unfair. The man did the right thing by sharing his findings; he even presented a case study. When I addressed Keil with the very sinister failure described above, I was told that 1. They don't believe me (!) 2. They cannot run my program on a MCB2300 (OK; maybe it is due to some incompatible XRAM settings/NOR flash etc.).
You know what? This gives me extra motivation to try to reproduce the startup problem I reported about above on an evaluation board. I will of course report the results!
The man did the right thing by sharing his findings;
No, he didn't share findings. He just cried wolf.
he even presented a case study.
Not here he didn't. Only after persistent prodding, he presented rather meaningless code snippets and repeated incorrect conclusions like "code worked in one compiler version, so code itself must be correct", even after having been repeatedly informed about their fallacy.
Nothing can ever, possibly be a "case study" of a suspected compiler bug without the actual(!) compilable source code, complete set of compiler settings, and corresponding machine code exhibiting the problem.
1. They don't believe me (!)
Well, given your track record in this forum, compared to that of Keil (including ARM's compiler division, who make the RealView line of compilers), frankly, I think they're entitled to that position. A subjectively estimated 95% of all compiler bugs claimed by users, aren't. A reported bug that a compiler vendor can neither reproduce on equipment available to them, nor see directly by inspection of generated machine code, doesn't exactly bias that ratio in your favour, either.
As a rule, extraordinary claims require extraordinarily good proof to back them up. We've seen pretty extraordinary claims here, paired with just about no proof at all.
Very well then. We'll see what I come up with!
By the way, for your information:
1. I did find a linker bug in MDK 4.12 (acknowledged by Keil and reproducible on small images (they won't link), fixed in MDK 4.13.
2. I believe "IB Shy" also mentioned that he has found a series of compiler bugs presumably fixed in MDK 4.13 !
#But you're not in any position to publish such a warning. You have neither the factual evidence #nor the community standing to back up your claims.
I have no access to Keil nor to the device, until Monday at work. I cannot install Keil at home unless I buy it. I could investigate this issue in some "spare" time at work. But I am not payed for debugging Keil and find stuff like this.
I have prepared 2 bug reports to Keil intl before this one. One of them was reproducible even inside emulator.
If everything works for you with 4.13a fine, it is OK, simply ignore this.
Jaroslav Fojtík,
Please don't give up! This is the only way to improve the Keil/our products!
You're not being asked to de-bug it - you're just being asked to produce conclusive evidence that a bug actually exists!
Taking your car analogy, you would need to prove that the car really was susbstantially underperforming, and that this was not due to your mis-handling of the vehicle; eg, carrying excessive loads or driving with the handbrake on...