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.
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 !
"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.
I have uploaded 4 images here:
www.penguin.cz/.../K312_before_call.gif www.penguin.cz/.../K312_after_call.gif
www.penguin.cz/.../K313_before_call.gif www.penguin.cz/.../K313_after_call.gif
Please look carefully at &c depicted in Kxxx_before_call and address buff depicted in Kxxx_after_call. When you feel that <a>Keil 3.13 is as rock stable</a> ignore this post. For me a code crashes on protection fault. I expected to solve this issue not with you but with Keil. When some of you is Keil developper, please contact me at Email JaFojtik(AT)seznam(DOT)cz.
Hi,
After email communication with Jaroslav, we (he and I) have come to the conclusion that this is not a compiler bug.
The debugger appears to be reporting erroneous values, and when hard printf()s were added to print the values they appeared correct. This would indicate that the problem is likely to be elsewhere.
From RVCT's point of view there does not appear to be a code generation problem.
Kind regards,
James Molloy Graduate compiler engineer, RVCT, ARM.