Avoid using Keil 4.13a - it generates defective code

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 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...

I had a problem today, whereby a previously working bit of code "stopped working" when compiled with 4.13. I started the debugger and stepped through the code, and found that a local variable was being stored in r9, we then had a switch statement switching on this "local variable". 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. This then meant that when the "local" was passed into the function, r9 had become corrupted, and therefore it had incorrect functionality. Recompiled the code with aditional debug code, but it always failed in the same way. Loaded 4.11 back onto the PC, and recompiled the code, and the exact same code now functions as expected!
I understand what people say about not being able to trust the debugger to report values correctly, but the code did not work with 4.13, but worked fine with 4.11.
This seems to be similar to the original post on this thread reporting an issue with using local variables and passing them into functions.
Think i am going to stick with 4.11 until I hear more from Keil.

Steve F,

This is very worrying indeed.
You did provide Keil with sample code, right...?

Hi Steve,

please send a small test application to Keil Support (support.intl@keil.com). It is more or less impossible to provide a workaround or fix for such problems without taking a look to the code and analyzing it!

Best regards,
Alexander Zaech

Alexander,

Man, I knew it !

Alexander,

Could you let us know whether you receive anything from Steve F and (more importantly) whether it is a genuine issue.

Thanks.

Similarly for Jaroslav Fojtík (the OP) and/or Martin Cupak...

It seems that false (?) bug reporting is the new form of trolling...

*#@&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.

So far, I'm not aware of any bad behaviour that is compiler related.

So far, I'm not aware of any bad behaviour that is compiler related.

Me neither!
F@%$ing morons!