arm-elf inline assembly problem (gcc bug?)

[Jeremy Linton <jli1010.NOSP_M@hotmail.com>]

I am running a self built gcc 3.0.3 from a few months ago. Its been
working fine until last a week or so when I wrote the following code.


//reads a single byte from the IO port set by PioSetAddress
unsigned char PioReadChar(void)
{
   PioController->WO_OutputDisable=0xFF; //set the data pins for input
   PioController->WO_InputFilterEnable=0xFF;
   int ret;
   //each PIO toggle takes ~90ns
   __asm__("mov r5,#0x400\n\t"
     "mov r6,#0x1000\n\t"
     "str r5,[%3]\n\t"
     "str r6,[%1]\n\t"

     "ldr %0,[%2]\n\t" //reading the byte a few times is a cheap way to
figure out my delay
     "ldr %0,[%2]\n\t" //since I know exactly how long (in real time)
the ldr is taking...
     "ldr %0,[%2]\n\t"
     "ldr %0,[%2]\n\t"
     "ldr %0,[%2]\n\t"

     "str r6,[%3]\n\t" //damn!!??  gcc 3.0.3 sometimes reuses a register
for both %0 and %3!
     "str r5,[%1]\n\t"
     "str r5,[%1]\n\t"//stick in the min change time of 135ns
     "str r5,[%1]\n\t"

     : "=r" (ret)
     : "r" (&PioController->WO_ClearOutputData),"r"
(&PioController->RO_PinDataStatus) , "r"
(&PioController->WO_SetOutputData)
     : "r5", "r6"
    );

   return ret;
}


which sometimes is giving me output which looks like (it varies
depending on the -O).


0x1017e0 <_Z11PioReadCharv+52>: str     r5, [r3]
0x1017e4 <_Z11PioReadCharv+56>: str     r6, [r0]
0x1017e8 <_Z11PioReadCharv+60>: ldr     r0, [r2] <--- Note the R0 reuse
0x1017ec <_Z11PioReadCharv+64>: ldr     r0, [r2]
0x1017f0 <_Z11PioReadCharv+68>: ldr     r0, [r2]
0x1017f4 <_Z11PioReadCharv+72>: ldr     r0, [r2]
0x1017f8 <_Z11PioReadCharv+76>: ldr     r0, [r2]
0x1017fc <_Z11PioReadCharv+80>: str     r6, [r3]
0x101800 <_Z11PioReadCharv+84>: str     r5, [r0] <--- core dump, r0 has
the value loaded not the original r0 value
0x101804 <_Z11PioReadCharv+88>: str     r5, [r0]
0x101808 <_Z11PioReadCharv+92>: str     r5, [r0]


I've been compiling it like.
arm-elf-gcc -DUNIX -g -c -O -Wall -fno-exceptions -fno-rtti Ethernet.cpp

Anyone have any suggestions? Has this problem been fixed in a newer gcc?
I don't want to go through the pain of upgrading if it there haven't
been any bugs like this fixed.  I would explicitly control the register
assignments, but I'm not sure how to do it with the arm.

BTW: remove the ".NOSPAM"  for a functional address.


                Thank you for you time,
                                    Jeremy Linton