Is this a compiling error?

You may be victim of optimization.
The debugger doesn't step through your source code. It steps through the binary code on teh MSP and then does a backwards search to find the related source code. However, in some cases the compiler has optimized the code so that more than one source code line is related to the same binary location. In this case it shows the first one found.

In this specific case, I can imagine that the code is optimized to look like this:

mov -1, R13
cmp #4,R15
jn end
// do the rest
mov 0, R13
end:
mov R13,R15
ret

You see, the result value 0xffff is set before executing the IF and if the comparison is true, it jumps to the end of the function - at the same place where it arrives when nLn>3. When you hit the breakpoint there, the debugger will show the first code line associated with this address, which is tthe first return, while you really are a t the second.

For debugging, disable any code optimization to prevent this type of confusion. And when you do the final test of the optimized code, take a look into the generated assembly and don't rely solely on the C source code.

Dear Jens-Michael,

Thank you for your explaining. Do you mean that I don't  need to care the result of the variable in debugging mode? 

Sunglin.

Sunglin Chen said:

Do you mean that I don't  need to care the result of the variable in debugging mode? 

Well, you shouldn't debug when the code has been optimized. Or at least look at the assembly code rather than the C source when debugging optimized code.
Usually, what looks unexplainable on the C source becomes clear when looking at the assembly code.
You should open the assembly view panel and single-step through this function on assembly level.

If you see something odd, you definitely shouldn't ignore it, but rather seek for an explanation. It's just about being a bit more investigative. Out of 100 cases where a compiler bug was suspected, 98 or 99 were caused by other reasons. That means, there are compiler bugs, but they are very rare.