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.
Sorry - I got the impression you were from Keil!
Hi Andy,
the issue Tamir reported was related to the debugger. If you also facing an issue please create a small test project which shows the problem and send it to Keil Support (support.intl@keil.com). I will take a look and provide a patch if required.
Best regards, Alexander Zaech Senior Support Engineer Keil - Tools by ARM
This would be a question for Keil.
Thanks,
James
Good.
But there do appear to be debugger issues?
Are these related to the debugger issues that Tamir mentioned?
Can you give an indication of where the debugger can be trusted, and where it can't?
"...there does not appear to be a code generation problem."
Thanks for the info.
Hi,
[Copy-pasting from my reply above, which was a reply direct to the OP]
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.
Once it got to the correct case, the code then passed this local variable into another function. On single stepping we found that the compiler was using r9 during the switch statement to determine which case was a match.
when a switch "got to the correct case" what does it matter what happene to the value switched on
Erik
Indeed!
And the alleged bugs may, indeed, be there - but, as you say, we have (as yet) seen no sufficient evidence of a problem on this thread...
No - as already noted, it is very old!
I think it's already been mentioned in this thread that it is a common response of a less-experienced developer to be quick to blame the compiler...
Which is one of the reasons why it's so important to have definite, compelling evidence of a bug.
"Lack of evidence of bugs is not evidence of lack of bugs."
True. It's one of those situations where you can prove there is a fault, but not prove there is not.
However, the bug that was being described seemed quite fundamental - And the chance of hitting a fundamental error of that nature would be quite high with a reasonably large project.
I have seen no sufficient evidence of a problem on this thread and Keil have not confirmed that there is any such problem.
So on balance, it would surely be preferable to stick with Keil's current release (rather than go back to something that Keil knows created bad code) until someone comes up with a substantiated and compelling reason not to use it.
"F@%$ing morons!"
Lack of evidence of bugs is not evidence of lack of bugs. I don't think there exist any C/C++ compiler that doesn't contain at least one source code processing or code-generating bug, and no runtime library without a bug. The question is just how easy it is to trig the error.
So far, I'm not aware of any bad behaviour that is compiler related.
Me neither! F@%$ing morons!
*#@&ing £%~/ers need to get a life!
For what it's worth, I'm still using 4.13a on our project thats in development (NXP LPC3250, mix of ARM and THUMB mode). The resultant binary image has 300K bytes of code. Using 'go for broke' style optimisations.
It seems that false (?) bug reporting is the new form of trolling...
View all questions in Keil forum