Re: Bug in latest IAR MSP430 compiler optimization???

In message <C6Kdnd_ktoaTDorVnZ2dnUVZ8uOdnZ2d@xxxxxxxx>, David Brown <david.brown@xxxxxxxxxxxxxxxxxxxxxxxxxx> writes
larwe wrote:
On Apr 29, 4:04 am, David Brown <da...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

Are you going to give us a clue as to what this bug is? Until you post
something more concrete, this is merely FUD. But if it is a real bug,
I don't have the code here at work, but the gist of it is that I have
a subroutine which does something like this:
void mysub(int a, int b)
{
const unsigned char *src, *tmpsrc;
int i,j;
src = pointer_to_const_data_struct;
for (i=0;i<8;i++) {
tmpsrc = src; // BAD LINE
for (j=0;j<3;j++) {
call_another_func(*(tmpsrc++),0);
} // j-loop
src += 3;
} // i-loop
} // mysub
[the reason for doing the arithmetic this way is because the code will
have to support some more complicated cases in future - I realize
there are other ways of doing the same thing].
As shown, built in maximum speed optimization mode, the code fails.
The reason appears to be that on the second iteration through the i-
loop, the value for "src" (which was in a register) got corrupted,
probably during call_another_func(). Either of the following will fix
the problem:
- move the src declaration so it becomes a global variable, or
- turn off speed optimization
I can post the whole project somewhere if someone actually wants to
look in detail. It's going to be public domain code anyway.


Any chance of posting the generated assembly for this? It should not be hard to follow, to see where the problem lies, if call_another_func is declared extern (to avoid it being inlined by the optimiser).

The problem has been found see below:-

In message <3b2e11dc-393f-4eef-8790-8ea6d4245d02@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, "andlind@xxxxxxxxx" <andlind@xxxxxxxxx> writes
Thanks for the code, I managed to add some parts to the code to get it
to compile. I can confirm that you indeed found a problem in the code
generator. The cause was much more complex than you guessed, it
contained a problem with register allocation, in the presence of post-
inc:s and unrolling, where "tmpsrc" and "src" variables were placed in
the same register, which clearly is wrong.

It has been assigned bug id EW20095, and it will be fixed in the
V4.11A release which we are in the process of finishing. It will be
available relatively soon.
Thanks for finding this problem!
-- Anders Lindgren, IAR Systems
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

As Anders says it is not as simple as you might think. To fix something like this is more than a simple patch. Well the code may end up being a simple patch but the rigorous checking and cross checking required for side effects is substantial before you do full regression testing.

The tests compiler companies do are quite extensive. Usually one or both of Plum-Hall or Perennial plus several sets of in house test suites for things like maths, assembler etc

One thing all the compiler writers I know say is the problem is not in finding the bug but how to fix it with not putting more in. The level of testing required afterwards is out of the reach of most programmers.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



.

Quantcast