Object file questions

[Timo Sintonen via D.gnu]

On Sunday, 17 August 2014 at 14:47:57 UTC, Johannes Pfau wrote:
> Am Sun, 17 Aug 2014 14:36:53 +0000
> schrieb "Timo Sintonen" <t.sintonen at luukku.com>:
>> 
>> But the register corruption is still an issue. My tls function 
>> clearly uses r3 and does not save it.
>> 
>> Johannes, do you know the arm calling system? Is it caller or 
>> callee that should save r3?
>> In this case it is my function that has one function inlined 
>> that has another function inlined that contains a compiler 
>> generated function call. Could this be a bug in the compiler 
>> that it does not recognize the innermost call and does not 
>> save registers?
>
> r3 is an argument/scratch register, the caller can't rely on its
> contents after a function call. This could also be caused by 
> the inline
> ASM.

I have had some weird bugs lately and then I looked my other 
object files.
I think there is a bug because I found more like this:

This is a class function (actually a constructor) that writes 
constant values into two variables, one is a static class 
variable in tls an  the other is an instance variable

   27 0000 10B5     		push	{r4, lr}
   28 0002 0346     		mov	r3, r0
   29 0004 FFF7FEFF 		bl	__aeabi_read_tp	@ load_tp_soft
   30 0008 034A     		ldr	r2, .L3
   31 000a 41F23421 		movw	r1, #4660
   32 000e 7424     		movs	r4, #116
   33 0010 1150     		str	r1, [r2, r0]
   34 0012 9C60     		str	r4, [r3, #8]
   35 0014 1846     		mov	r0, r3
   36 0016 10BD     		pop	{r4, pc}
   37              	.L4:
   38              		.align	2
   39              	.L3:
   40 0018 00000000 		.word	.LANCHOR0(tpoff)
   41

In line 28 the this pointer is saved to r3, then the call in line 
29 returns the tls start address in r0. __aeabi_read_tp uses r3 
to fetch the address so r3 is corrupted  R3 is used in 34 to 
store to address this+8 and then r3 is moved back to r0 returning 
incorrect value for this.

Is this a gdc or gcc bug?