[fpc-devel] fpc bug with M1

[Florian Klämpfl]

> Am 30.12.2021 um 21:07 schrieb Jonas Maebe via fpc-devel <fpc-devel at lists.freepascal.org>:
> 
> On 30/12/2021 21:03, Florian Klämpfl via fpc-devel wrote:
>>> Am 30.12.2021 um 20:57 schrieb Jonas Maebe via fpc-devel <fpc-devel at lists.freepascal.org>:
>>> 
>>> On 30/12/2021 20:55, Martin Frb via fpc-devel wrote:
>>>> On 30/12/2021 20:46, Jonas Maebe via fpc-devel wrote:
>>>>> On 30/12/2021 18:06, Florian Klämpfl via fpc-devel wrote:
>>>>>> 
>>>>>> Ah yes, or like this. Nevertheless, the question is whether the ldrsb w0,[x0] is correct or not.
>>>>> 
>>>>> Yes, I was unclear: with the "I don't know/remember where this is done" I meant "changing the load of the unsigned byte type into a signed load". I can't think immediately of a reason either why this is done.
>>>> "unsigned byte"? The pointer in the pascal code is a pint8 => signed.
>>> 
>>> Oh, I thought it was puint8. Then it makes sense. c90616944d3bde7b36e924d27a0790195d61f95c applies both to OS_8 and OS_S8.
>> Yes, but the question is: if we load a shortint into a register, do we need to sign extend it to 32/64 bit or not? I tend more and more to say that we shouldn’t require this.
>> Neither clang nor gcc seem to expect this for arguments/return values: https://godbolt.org/z/sv5fPP6GM
> 
> This is not related to arguments/return values.

Yes and no.

Gcc compiles

unsigned char f(int i)
{
    return i;
}

into a single ret.

This means, that we cannot assume that the upper part of registers is cleared. Of course, we could limit this to function calls but I guess doing it consistently is easier to handle.

> We do the same on on PPC, and afaik on all architectures that don't have 8/16 bit subregisters. I initially did it on PPC because it simplified code generation a lot and solved all kinds of small issues I got otherwise because non-cleared higher parts of registers were used. Maybe with our current code generators it would work better.
> 
> 
> Jonas
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org <mailto:fpc-devel at lists.freepascal.org>
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel <https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20211231/8c2a9b12/attachment.htm>