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.
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?
We keep older compiler versions for older products, and only switch compiler version when making larger code changes requiring huge amounts of new qualifying tests.
In some cases, the compiler version used is also reported in certification documents where a tool change may result in a very costly external recertification.
It's only during the development phase that it is reasonably simple to switch between different compiler versions.
Closed-source or not really desn't matter. We have quite a lot of C/C++ code that is being built with gcc toolchains from 2005.
When a program fails, debugging is needed. That debugging should be thorough enough that it can be deduced if the error was in the source code or in the compiler. But that obviously requires that the person debugging the code doesn't fall for invalid assumptions about what is correct or not. And that includes the understanding that the debugger will not always be able to display the correct values because optimization has changed instruction order or life span of variables.
Here is a small test case that I am now going to send to Keil failing the debugger:
int main( void ) { int x1 = 1, x2 = 2, x3 = 3, x4 = 4, x5 = 5, x6 = 6, x7 = 7, x8 = 8, x9 = 9, x10 = 10, x11 = 11, x12 = 12, x13 = 13, x14 = 14, x15 = 15, x16 = 16; for (;;) { ++x1 ; ++x2 ; ++x3 ; ++x4 ; ++x5 ; ++x6 ; ++x7 ; ++x8 ; ++x9 ; ++x10 ; ++x11 ; ++x12 ; ++x13 ; ++x14 ; ++x15 ; ++x16 ; } }
Compiled using ARM code (LPC2478), no microlib, compiler optimization 0, no cross module optimization. On my system, the values of x14, x15, x16 are all set to 0x10 (according to the debugger), then incremented in the loop. Why does this happen? Well, the storage of x14 happens like this:
0x00000178 E3A0E00E MOV R14,#0x0000000E 0x0000017C E58DE008 STR R14,[R13,#0x0008] 17: x15 = 15,
and the debugger displays the contents of the stack without taking the offset into consideration! Please copy-paste this program and try it will MDK 4.13a in a simulator.
This seems to be an entirely unrelated problem?
I really think it would be better to put it in separate thread - you can always give a link to this one...