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.
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...
"I believe "IB Shy" also mentioned that he has found a series of compiler bugs presumably fixed in MDK 4.13 !"
I found one bug in code produced by the compiler, with regards inline optimisation. Fixed in 4.13a.
Much like Tamir's experience, I have previously received the "do not believe" from the support team, where they just said it was my code at fault - I gave them plenty of evidence that they seemed to simply ignore. I spent a crazy amount of time tracking the problem down further and I finally persuaded them that it was actually a fault in their code. It was subsequently fixed (way after I had finished the project using a fix of my own).
When I suspected a compiler fault, I spent a considerable amount of time tracking it down to the absolute minimum code snippet and then documenting the details. I think, as a result of the detail and evidence I provided, I got a reasonably swift acknowledgement of the problem.
But ... I think it was time well spent, because in the long run I probably got a fix a damn sight quicker than if I'd just sent an email to Keil saying the compiler produced defective code.
My problem with the OPs original text is that his evidence is really poor, in both explanation and example provided. He may have found something, we don't know. Looking at it from Keil support's side, I hope they have enough to go on - At the moment, I dont think they do.
Well, guys, just a comment: I would say that precise locating a bug in the disassembled machine code is pretty close to debugging - keeping in mind that the the Keil development suite is not open source... You are also lucky that your employer is paying hours and/or days (each of you know how much...) of your extra work to locate the bug in development tool and provide the evidence. No doubt it is a challenging task - and rather satisfactory if successful - but most of the programmers are hired to write a software and not to be testing the commercial dev tools ;-)
"You are also lucky that your employer is paying hours and/or days (each of you know how much...) of your extra work to locate the bug in development tool and provide the evidence."
But, if you don't know that the problem is with the compiler, you are potentially just giving Keil support the task of finding a bug in your code. They are not paid to do that.
That is entirely irrelevant!
You are alleging that there is a fault in the output from the compiler. So all (sic) you need to do is to provide a concrete example of where that output is manifestly wrong - there is no need whatsoever to delve into the inner workings of the tools!
Is your employer, perhaps, being naive in thinking that switching fron one compiler version to another is a trivial task?