Bad x86_64 code generated

[simonjwright]

This is just a heads-up in case it indicates a possible future problem.

While exploring an issue which turned out to be caused by the different ABI for variadic arguments, I tried building an x86_64 compiler on aarch64 from the 12.1-darwin-release-0 branch (using an x86_64 compiler built from the 12.1.0 release code), and got what looks like a recurrence of PR64540:

/Volumes/Miscellaneous1/x86_64/gcc-darwin-arm64-x86_64/./gcc/xgcc -B/Volumes/Miscellaneous1/x86_64/gcc-darwin-arm64-x86_64/./gcc/ -B/Users/simon/tmp/gcc-12.1.0/x86_64-apple-darwin15/bin/ -B/Users/simon/tmp/gcc-12.1.0/x86_64-apple-darwin15/lib/ -isystem /Users/simon/tmp/gcc-12.1.0/x86_64-apple-darwin15/include -isystem /Users/simon/tmp/gcc-12.1.0/x86_64-apple-darwin15/sys-include --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk   -c -g -O2  -fno-common  -W -Wall -gnatpg -nostdinc   g-locfil.adb -o g-locfil.o
/var/folders/ch/k_zwspdx3qsfbt1_x21zld6m0000gn/T//cc4aejFY.s:12507:2: error: ambiguous instructions require an explicit suffix (could be 'fisttps', or 'fisttpl')
        fisttp  -408(%rbp)
        ^
/var/folders/ch/k_zwspdx3qsfbt1_x21zld6m0000gn/T//cc4aejFY.s:12767:2: error: ambiguous instructions require an explicit suffix (could be 'fisttps', or 'fisttpl')
        fisttp  -408(%rbp)
        ^

[iains]

I am not quite following what you've built and how.

• would not recommend using release 0, release 1 was issued to deal with a serious arm64 issue.
• you are building a cross-compiler for x86_64 on aarch64? (if so, how have you configured it?)

At present, I have no access to Arm64 so will not be able to investigate directly.

[iains]

hmm .. or maybe are you trying to build a 'Canadian cross' on x86_64?

--target=x86_64-apple-darwin2x --host=aarch64-apple-darwin2x --build=x86_64-apple-darwin2x ?

or --target=x86_64-apple-darwin2x --host=aarch64-apple-darwin2x --build=aarch64-apple-darwin2x?

canadian crosses are much more tricky than regular crosses - because the configure script cannot run some of the tests (since tools for $host will not run on $build)

[simonjwright]

I have code which I build using x86_64-apple-darwin15 (released GCC 12.1.0, running on darwin21) and which runs fine, but fails when built using aarch64-apple-darwin (your release 0). Since I can run an x86_64 compiler on aarch64 to generate an x86_64 executable, I thought, I want to build release 0 for x86_64 to see if my problem is related to code get in release 0. So I tried to build release 0 using the x86_64-apple-darwin15 compiler mentioned above on the aarch64-apple-darwin, with the failure reported here.

I guess I managed to confuse the compiler somehow; I just built release 0 with the x86_64-apple-darwin15 compiler on an x86_64-apple-darwin21 machine; no problems.

Sorry for the noise.

[simonjwright]

Just a note: the error arises when the assembler is given x86_64 code but is running in an aarch64 shell; I guess gcc doesn't think it needs to tell as -arch x86_64.

My fix: if building x86_64-apple-darwin on arm64 hardware, first do arch -x86_64 /bin/bash.

[iains]

Just a note: the error arises when the assembler is given x86_64 code but is running in an aarch64 shell; I guess gcc doesn't think it needs to tell as -arch x86_64.

My fix: if building x86_64-apple-darwin on arm64 hardware, first do arch -x86_64 /bin/bash.

Yes, that is what I always do; you are correct something internal to the Rosetta/subprocess-launch gets confused otherwise - you will also see complaints about bad instructions in some cases.

So, FAOD, (given a correct build environment) we do not have an issue with x86_64? (I think my previous fix should work for that and powerpc) but we need to find an equivalent for aarch64.