Watch window error (stack variable)

Could you please have a look at the following source code:

#include <stm32f10x.h>                       /* STM32F103 definitions         */


class Test  {
public:
  static int i1;
  static int i2;
  static int i3;
  static int TestFunc( long l1, long l2);
  static void foo( long* pl);
  static long foo2();
};

void Test::foo( long* pl){
  pl[1]= pl[0];
}
long Test::foo2( ){
  return i1+i2+i3;
}

int Test::TestFunc( long l1, long l2)  {
  long al[8];
  if( l1 != foo2())
    return 1;
  al[0]= 1;
  al[1]= l2;
  foo( al);
  return 0;
}

Test T;
int Test::i1 = 1;
int Test::i2 = 0;
int Test::i3 = 0;

int main(void)  {
  T.TestFunc( 1, 2);
  while(1);
}

(sorry that it is a bit long - see the comments below. I used STM32F1xx with define STM32F10X_MD and selected chip STM32F103RB, because with this setting I get the simulator to run - unfortunately the simulator does not run with my STM32F4 projects (see other thread, I just generated)).

I compiled with optimization level -O1, is used uVision V4.70.0.0 (ArmCC V5.03.0.24).

When I put a breakpoint to the function "TestFunc", and then watch the variable "al" in either the window "Watch1" or "Call Stack - locals", then something very strange happens after the line "if (l1 != foo2())". The watch addresses then somehow re-organize, because arter this point the variable "l1" shows "<not in scope>" - which really is smart.

Just stupidly the address of "al" then switches back from 0x658 (which is correct, and identical to the stack pointer address at this point) to 0x638. Then of course "al" is not displayed any more correctly.

This strangely requires some very bizarre preconditions, this is why this test program has to be quite long:
- The function TestFunc has to have 2 variables (if I strip l2, this does NOT happen any more).
- In the function foo2 it is required to add 3 variables "i1+i2+i3" - if I instead try with "return i1;" or "return i1+i2;", again this does NOT happen any more.
- The instruction "if( l1 != foo2()) return; " of course is required, as this somehow produces the trouble (if I replace it by "long l4= foo2(); if( l1 != l4) return; " again this problem does NOT occur.

This really is very strange - I needed about 4 hours to strip a very large software to this smaller test program - at first I suspected some stack problem in my larger software (of course I must admit, that watching local variables in optimized code is a very challenging task, and Keil uVision is doing really very well, but such a behaviour is NOT very nice ...).