I'm trying to build ppcrossx64 on my macOS darwin Tahoe apple silicon machine with a ppca64 built from fpc trunk and Xcode 26.6 and no Rosetta running.

Should I expect that to succeed?

I can get ppcx64 if I let Rosetta build it. And using ppcx64 inside Rosetta I can build x86_64 binaries on my macOS machine. However, I would like to be able to actually cross compile x86_64 on apple silicon without Rosetta involvement.

I am getting the following errors when pp.pas is being compiled:

/Users/djenkins/Source/BCTrunk/Lazarus/fpc/compiler/ppc -Ur -Xs -O2 -n -Fux86_64 -Fusystems
-Fu/Users/djenkins/Source/BCTrunk/Lazarus/fpc/rtl/units/aarch64-darwin -Fix86_64 -FEx86_64/bin/aarch64-darwin -FUx86_64/units/aarch64-darwin -XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -dRELEASE -dBC_FPC_BUILD -n @/Users/djenkins/Source/BCTrunk/Lazarus/fpc/../fpc.cfg -dlegacysocket -dLIBC_OLDERRNO -dx86_64 -Fux86 -Fix86 -Sew -o/Users/djenkins/Source/BCTrunk/Lazarus/fpc/compiler/ppcrossx64 pp.pas <stdin>:5227:9: error: expected compatible register or logical immediate mov x1,w23
^
<stdin>:5241:9: error: expected compatible register or logical immediate mov x1,w23

I did some searching in the gitlab issues and didn't see anything related.

Happy to create a bug report in gitlab if needed.

Thanks
David Jenkins

Hi,

David Jenkins wrote

I'm trying to build ppcrossx64 on my macOS darwin Tahoe apple silicon machine with a ppca64 built from fpc trunk and Xcode 26.6 and no Rosetta running. Should I expect that to succeed?

Yes. Or at least fail with a meaningful error message, and not with what you got.

Please do so. This looks like a genuine bug in the ARM64 codegenerator, I managed to reproduce it. Without the optimizer enabled (-O- argument), it actually runs into an internal error 200308299.

Charlie

Hi,

BTW, this isn't a Darwin (macOS) issue. I reproduced it while doing the a build from ARM64 Linux to x86_64 Linux. So it's a generic ARM64 code generator bug.

Charlie

That sounds like it might be a job for me in that case, if not my doing.  The fact that an internal error is generated when the peephole optimizer is turned off does imply there's something deeper going on though.

Kit

That error was generated when I tried building ppcross64x from my bootstrap ppca64-3.2.2 compiler.

If I first use ppca64-3.2.2 to build a trunk ppca64-3.3.1 and then use that to build ppcrossx64, I do get a ppcrossx64 built but then when it tries to build the rtl it fails with

/Users/djenkins/Source/BCTrunk/Lazarus/fpc/compiler/ppcrossx64 -dFPC_USE_LIBC -Px86_64 -XX -CX -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fi../bsd -Fi../bsd/x86_64 -Fi../darwin/x86_64 -FE. -FU/Users/djenkins/Source/BCTrunk/Lazarus/fpc/rtl/units/x86_64-darwin -dBC_FPC_BUILD -n @/Users/djenkins/Source/BCTrunk/Lazarus/fpc/../fpc.cfg -dlegacysocket -dLIBC_OLDERRNO -dx86_64 -dRELEASE -Us -Sg ../bsd/system.pp genmath.inc(606,5) Fatal: Internal error 2014051001 Fatal: Compilation aborted
make[5]: *** [system.ppu] Error 1
make[4]: *** [fpc_smart] Error 2
make[3]: *** [darwin_smart] Error 2
make[2]: *** [rtl_smart] Error 2
make[1]: *** [build-stamp.x86_64-darwin] Error 2
make: *** [crossinstall] Error 2
/Applications/Xcode-26.6.app/Contents/Developer/usr/bin/make -C compiler distclean
<stdin>:76571:1: error: assembler local symbol 'Ld23' not defined

^
<stdin>:76571:1: error: assembler local symbol 'Ld8' not defined

Which is different than the 200308299 error you saw but the above was with -O2.

I'll create a gitlab bug report.

So the Internal Error is in a case-block where it tries to write a real-typed constant to an assembly dump (which may be passed into an external assembler), but the type is not recognised/supported.  With that in mind it might be due to my recent Currency changes.  I've got my work cut out!

Kit

With that in mind it might be due to my recent Currency changes.

If it is 0adf046ea0, there is an open report on that commit with reproducers:
41865. Four defects, all of them the nf_is_currency flag not surviving somewhere
- across a temp, across unary minus, across inlining, and the tightened rescaling condition in tmoddivnode. Two have patches, two only a diagnosis (div/mod and -Oofastmath). The two unpatched ones may be closer to what you are looking at than the patched ones.

A data point from a third host, for what a negative is worth: on aarch64-win64 that cross build goes through. Same command as David's, trunk 416b51be87, at -O2 and at -O-, with and without the 41865 patches - no bad mov, no internal error. Nothing in compiler/aarch64 or compiler/assemble.pas has changed since that snapshot, and 0adf046ea0 is in it, so it does not look like a newer regression on that side. Which would leave the host ABI as the difference against your Linux and David's Darwin.

Sven