On testsuite/gcc.target/i386/long-double-64-1.c, gcc produces a call to __multf3 on arm64 and the test checks that such a call is not generated on x86_64. $ cat a.c long double foo (long double x) { return x * x; } On arm64: $ gcc -O2 -S -o- a.c foo: stp x29, x30, [sp, -16]! mov v1.16b, v0.16b mov x29, sp bl __multf3 ldp x29, x30, [sp], 16 ret On x64: $ gcc -O2 -S -o- a.c foo: endbr64 fldt 8(%rsp) fmul %st(0), %st ret Why GCC does not generate an fmul on arm64 instead of calling libgcc? There is a related performance issue in libGeos: https://github.com/libgeos/geos/issues/509
Arm64 does not have native higher than 644bit floating point. That is why it is a libcall. X86_64's long double is 80bit fp too.
If you want to have a consistency between platforms, it might be best if you use _Float128 instead of long double but _Float128 is not supported on all targets really. It is only supported on targets which have support for IEEE 128bit FP which includes x86_64, arm64 and PowerPC. Again this is not really a bug or anything GCC can do better unless the newer hardware comes out which has native support. See https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html for more details on this.