Ok, I got a bit further.
Assuming the following
(and not counting on Interlocked... doing any Barriers itself)
Thread 1
Foo := val; // normal assign
WriteBarrier; // make sure above write to Foo is executed, before the
next write to flag
InterLockedIncrement(Flag); // needed for the
Hi,
The latest FPC trunk can now generate code that targets macOS/AArch64.
The testsuite results are good and Lazarus also works when compiled with
this backend (although I haven't extensively tested it).
Like for other targets, most additional testsuite failures compared to
using the built-in
Hi everyone,
So my new x86_64 laptop has finally arrived, although it will take a few
days to get everything reconfigured, as well as find the e-mail server
details so I don't have to keep using an antiquated webmail system to
communicate on this account!
Thank you so much to Chris Rorden for
That saved me so much work! I found the incorrect code - thanks Jonas!
Trunk:
...
mov x0,x22
bl SYSTEM_$$_NEWUNICODESTRING$INT64$$POINTER
mov x23,x0
lsl x2,x22,#1
mov x1,x23
cbnzx20,.Lj3808
adrp
Thanks Jonas - I'll see if I can pinpoint it now.
Gareth aka. Kit
On Sun 23/08/20 13:09 , Jonas Maebe via fpc-devel
fpc-devel@lists.freepascal.org sent:
> On 23/08/2020 12:48, J. Gareth Moreton via fpc-devel wrote:
>
> > I've found a pretty big optimisation that
> benefits most ARM platforms,
On 23/08/2020 12:48, J. Gareth Moreton via fpc-devel wrote:
> I've found a pretty big optimisation that benefits most ARM platforms,
> including AArch64, but I'm getting a few random test failures. My
> investigations suggest that functions like "fpc_chararray_to_unicodestr" and
> other string
Hi everyone,
I've found a pretty big optimisation that benefits most ARM platforms,
including AArch64, but I'm getting a few random test failures. My
investigations suggest that functions like "fpc_chararray_to_unicodestr" and
other string conversion routines are not being optimised properly
