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.
"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...
Before making any conclusions - how about adding a function that takes your variables x1 .. x16 as parameters, so the compiler may at least believe that you are using them?
Right now, you only have a rather large empty loop that doesn't produce any real work.
Next thing is that you must separate problems with debugger from problems with compiler.
You show a piece of assembler output - but isn't the x15 = 15 handled by assembler instructions after the source line? You show the assembler above the source line.
Per,
This is NOT a compiler issue at all - above, I referred to a debugger failure and that's what is happening here. The same problem applies to x14, x15 and x16.
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.
I probably should not have pasted "x15" alongside the assembly for "x14". Sorry, my bad.
Andy,
The damage is already done - will correct next time...
Yes, but remember that the original post had the subject line "Avoid using Keil 4.13a - it generates defective code" which is claiming a bug with the compiler. It really is important to perform a careful analysis before making an error report. A large percentage of developers will probably never see a true compiler bug, that isn't in reality a misunderstanding of what the compiler is expected to do.
All,
Keil support have provided me with DLLs that address the debugger issue above (wrong value displayed). I believe they will make them available to others as well.
So we know that there are debugger issues.
Therefore, to prove a compiler code generation bug, the OP needs to demonstrate both that it's not his own code that's faulty and that it's not a result of the known debugger issues...
To continue the car analogy, a false (low) reading on the speedometer would give the impression that the car's performance was poor...