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.
Have you got real hard evidence of your error? Have you given it to Keil? It only seems sensible and fair to provide as much detail as possible when making a claim about such matters.
I previously reported problems to Keil concerning 4.12 and inline optimisations. I included specific examples with full annotations of what I suspected were code generation errors.
Glad to say that they appear to be fixed in 4.13a. I, for one, will NOT be going back to 4.12.
Yes, I have reported this issue to Keil yesterday and no reply obtained yet.
I do not wish to bog down into details. In several cases compiler mis-compiled pointer to variable to a different location. In some cases C++ code called wrong ctor and so on... All these issues are not observable in 4.12.
Some construct like this passed completely different pointer. But this simple case would probably work fine. The real function had 4 parameters and some of them were passed correctly.
void proc1(void *p) { }
void proc2(void) { char c;
proc1(&c); }
I cannot attach image to this forum to demonstrate screenshot of Keil. I reverted back to 4.12 and any analysis would take me lot of time.
It must be at least as likely that the fault lies in your source code?
It is quite common that a change of compiler will bring out previously hidden faults in the source code that just happened not to manifest previously; ie, you were lucky with 4.12, but your luck has just run out with 4.13a.
Unfortunately, without any specific details, your accusation is just about worthless!
"mis-compiled pointer to variable to a different location"
What do you mean by that: was the pointer itself placed in a "wrong location", or did the pointer's value point to a "wrong location"?
"passed completely different pointer"
What do you mean by that?
"any analysis would take me lot of time"
Yes, of course - but without that proper analysis, it's just speculation...
#"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.
This has been my original report to Keil Intl before I have found that this issue affect also regular function call. I do not know what triggers this issue.
-------------------------------------------------------------------------- Please look at this image: www.penguin.cz/.../CtorFailure.gif
Dear Keil support,
I am facing a problem that automatic variables are not initialised properly - see attached image
I have debugged a code and ctor is called in both cases. But for a variable on stack it does not initialise object properly.
class string { private: static char Dummy; char *ch; unsigned int maxlen; unsigned int size; void resize(unsigned int NewMaxlen); public: explicit string(unsigned len); //explicit is expanded to private: for obsolette compilers public: string(void) {size=maxlen=0;ch=0;};
...................................................................
#It must be at least as likely that the fault lies in your source code?
Believe me, you are lucky because you are not facing this issue.
The only issue I have found, created a snapshot of, and reported to keil is the debugger reporting the wrong value of automatic variables. It is not easy to reproduce - changing one line of code will correct it! However, I did manage to reproduce a serious failure of the tool chain and and posted it to keil but they somehow failed to get it to run on an evaluation board (I need to do it myself). A function, not being called at all from anywhere in the software, will cause a controller "abort" upon startup. But when the function is removed - again, it has no side effects - the controller will startup correctly. I will try to reproduce it this week - the code is attached to a Keil case.
If you look at linked image, you could see two objects ss and ssss. Object ss is an automatic object, and it was not initialized properly.
It is very hard for me to prepare test-case snapshot that reproduces Keil bug from two reasons: A, I cannot send our proprietary code, so I have to write different code that triggers a bug. B, My manager expects me to work and not to debug a Keil.
But anyway, I will look at this issue deeper when Keil hotline answers me something.
"I have spent several hours with debugging a code ..."
Do you think several hours is enough to spend on a problem that is as important as you suggest?
Did you step through the assembler for the function in question to verify what was really happening?
You may be right when you say "it produces defective code", but it might be better for both you and Keil to get as much concrete evidence as possible for Keil to examine. I also have proprietary code, but I managed to narrow it down to just 4 lines of (faulty) assembler that was being generated from 30 lines of C source. When I handed it to Keil I was as sure as I could be that I had actually found a genuine, reproducable problem.
Hi guys, 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. So it apparently is not a bug in source code. 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. I'm a colleague of Jaroslav - I've seen this issues with my own eyes...
Bottom line: May be .13 in the version number is not happy enough number ;-)
I have a similar experience with Keil 4.13a.
The following code enters an infinite loop when compiling with optimization levels 2 or 3.
unsigned int x = 0x12; while (!((x & 0x02) && (x & 0x10))) {} // turn on LEDs here
I observed the infinite loop by turning on some LEDs after the loop. With O2 and O3 the LEDs remain turned off.
This was tested on the MCB2300 test board with µVision V4.13a.
Hello Roel,
please send a full example project to Keil Support (support.intl@keil.com). As long as Keil Support don't have an example to reproduce the problem we can't say anything about the root cause.
Best regards, Alexander Zaech Senior Support Engineer ARM Germany GmbH
Alexander,
Any luck this time around...?
I send a full project to the Keil support. I hope it proves useful when solving this problem, whether it is my own code or the compiler.
Regards, Roel