[fpc-devel] fpc bug with M1

[Jonas Maebe]

On 30/12/2021 17:16, Florian Klämpfl via fpc-devel wrote:
> Am 30.12.21 um 14:52 schrieb Jonas Maebe via fpc-devel:
>> On 29/12/2021 00:48, Martin Frb via fpc-devel wrote:
>>> I don't have an M1 myself, but according to the data from the thread 
>>> on the lazarus mail list, there is a bug in the 3.3.1 asm generator 
>>> for M1
>>>
>>> var pn8: pint8; // pointer signed byte
>>>
>>> In the below expression ...(not pn8^)...
>>>
>>> "pn8^" is loaded to w0 and sign extended. From this point onwards 
>>> operations on the value should be 32 bits (the value has been 
>>> extended, and the full 32 bits are later used).
>>> but "not" only affects the lowest 8 bit.
>>>
>>> Apparently in 3.2.2 (or was it 3.2.0) there was
>>> mvn w0,w0
>>>
>>> If someone can confirm tihs....
>>
>> It's probably caused by c90616944d3bde7b36e924d27a0790195d61f95c 
>> (Florian)
>>
> 
> Isn't the sign extension during the load wrong? Martin didn't post the 
> whole assemble code but I would expect that 3.2.2 produced an uxtb 
> instruction afterwards which hide the problem.

No, 3.2.2 afterwards sign-extendeds the result as a signed rather than 
unsigned value:

# [29] Result += (pn8^ shr 7) and ((not pn8^) shr 6);
         ldr     x0,[sp]
         ldrsb   w0,[x0]
         mvn     w0,w0
         sxtb    w0,w0
         lsr     w1,w0,#6
         ldr     x0,[sp]
         ldrsb   w0,[x0]
         lsr     w0,w0,#7
         and     w0,w0,w1
         sxtw    x0,w0
         ldr     x1,[sp, #16]
         add     x0,x1,x0
         str     x0,[sp, #16]

I admit I don't know/remember where this is done though, as AArch64's 
a_load_ref_reg doesn't seem to have any special logic that would do this.


Jonas