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@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?