Igor,
I have both a DTK and M1. I have not seen any bugs on the M1 that were not present on the DTK. However, there are several documented FPC bugs for situations where the optimization level is greater than -O1. My current approach is to develop everything with the FPC compiler (which is very quick to compile and nicely integrated into Lazarus) and then to compile the release builds with LLVM.
Optionally, for extra performance, I also add a couple of custom compiler options for LLVM that Jonas suggested. I do this by adding a couple lines to the .lpi file (I can not work out how to make a conditional for LLVM detection in the compiler options):
<CustomOptions Value="-dDisableLCLGIF
-Clflto
-Clfltonosystem"/>
So my build/notarization script cross-compiles and uses lipo to make a universal binary:
lazbuild -B --compiler=~/src/fpcllvm/lib/fpc/3.3.1/ppcx64 --ws=cocoa --cpu=x86_64 ~/src/MRIcroGL12/MRIcroGL_Metal_llvm.lpi
lazbuild -B --compiler=~/src/fpcllvm/lib/fpc/3.3.1/ppca64 --ws=cocoa --cpu=aarch64 ~/src/MRIcroGL12/MRIcroGL_Metal_llvm.lpi
Compared to the non-optimized FPC AArch64, this leads to substantially faster performance. Here are the times in milliseconds for a few tasks:
M1-FPC
init 329
minmax 319
rgba 189
M1-LLVM
init 126
minmax 81
rgba 104
I do expect FPC will close this gap as the AArch64 optimization matures - I urge everyone to help sponsor Kit's work on this
https://www.patreon.com/curiouskit/postsSince LLVM/Clang is what Apple uses for all their tools, it seems very optimized. All my Lazarus projects just work, including those that use OpenGL and Metal. I suspect this will resolve the bugs you are encountering, and should allow you to build perfectly fine M1 code on your DTK.