options.cc fails to compile

simonjwright commented 2 years ago

Commit af646be on master-wip-apple-si building on darwin 21.3.0 with GCC 11.2 x86_64-apple-darwin15 fails with


g++  -fPIE -c   -g -O2     -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/Volumes/Miscellaneous1/src/gcc-darwin-arm64/gcc -I/Volumes/Miscellaneous1/src/gcc-darwin-arm64/gcc/. -I/Volumes/Miscellaneous1/src/gcc-darwin-arm64/gcc/../include -I/Volumes/Miscellaneous1/src/gcc-darwin-arm64/gcc/../libcpp/include -I/Volumes/Miscellaneous1/src/gcc-darwin-arm64/gcc/../libcody -I/Volumes/Miscellaneous1/x86_64/gcc-darwin-arm64/./gmp -I/Volumes/Miscellaneous1/src/gcc-darwin-arm64/gmp -I/Volumes/Miscellaneous1/x86_64/gcc-darwin-arm64/./mpfr/src -I/Volumes/Miscellaneous1/src/gcc-darwin-arm64/mpfr/src -I/Volumes/Miscellaneous1/src/gcc-darwin-arm64/mpc/src  -I/Volumes/Miscellaneous1/src/gcc-darwin-arm64/gcc/../libdecnumber -I/Volumes/Miscellaneous1/src/gcc-darwin-arm64/gcc/../libdecnumber/dpd -I../libdecnumber -I/Volumes/Miscellaneous1/src/gcc-darwin-arm64/gcc/../libbacktrace   -o options.o -MT options.o -MMD -MP -MF ./.deps/options.TPo options.cc
options.cc:2969:3: error: 'STACK_USE_CUMULATIVE_ARGS_INIT' was not declared in this scope
 2969 |   STACK_USE_CUMULATIVE_ARGS_INIT, /* flag_stack_use_cumulative_args */
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [options.o] Error 1
make[1]: *** [install-gcc] Error 2
make: *** [install] Error 2```

iains commented 2 years ago

hmm.. interesting .. I do a native bootstrap (with GCC-11.2 as the bootstrap compiler, including Ada) and test, before pushing the new branch, each week normally. I also do a cross and a native cross on x86_64 Darwin20.

test results (and configuration line) https://github.com/iains/gcc-darwin-arm64/issues/30#issuecomment-1046006503

So .. I wonder, what's different here ( the machine I am using is not under my control so I cannot update stuff)

a) $ sw_vers ProductName: macOS ProductVersion: 12.1 BuildVersion: 21C52

b) clang --version Apple clang version 12.0.5 (clang-1205.0.22.9) Target: arm64-apple-darwin21.2.0

simonjwright commented 2 years ago

$ sw_vers ProductName: macOS ProductVersion: 12.2.1 BuildVersion: 21D62

$ clang --version Apple clang version 13.0.0 (clang-1300.0.29.30) Target: x86_64-apple-darwin21.3.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

You did warn that building on x86_64 might bring up problems! But in this case there seems to be a mismatch between gcc/opth-gen.awk and gcc/optc-gen.awk

$ awk --version awk version 20200816

iains commented 2 years ago

You did warn that building on x86_64 might bring up problems! But in this case there seems to be a mismatch between gcc/opth-gen.awk and gcc/optc-gen.awk

Well .. I do build on x86_64 (as well), but usually only on Darwin20 (the box I have Darwin21 on is slower)

... I'm using Xcode 13 there, so maybe there's some issue with awk - even though the version is the same.

$ awk --version awk version 20200816

=== the process:

do a native bootstrap - install
build a cross-compiler - install
build a native-cross (this does need a couple of tricky things to work properly - but it doesn't seem like this is your problem [yet])

iains commented 2 years ago

hmmm... are you using the aarch64-darwin branch to build the x86_64 native compiler?

If so, I have an idea about where the problem might be - tomorrow is rebasing day, let me see if I can track it down.

simonjwright commented 2 years ago

Of course, could be my configure args. These are what I’ve been using for building gcc branch master on El Capitan and providing to users - I test on Monterey since that’s my normal workhorse.

$ /Volumes/Miscellaneous1/src/gcc-darwin-arm64/configure --prefix=/Volumes/Miscellaneous1/opt/gcc-12.0.1 --without-libiconv-prefix --disable-libmudflap --disable-libstdcxx-pch --disable-libsanitizer --disable-libcc1 --disable-libcilkrts --disable-multilib --disable-nls --enable-languages=c,c++,ada --host=x86_64-apple-darwin21 --target=x86_64-apple-darwin21 --build=x86_64-apple-darwin21 --without-isl --with-build-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk --with-sysroot= --with-specs=%{!sysroot=*:--sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk} --with-build-config=no --disable-bootstrap

optc-gen.awk is identical to gcc master, but opth-gen.awk has 43 changes

simonjwright commented 2 years ago

hmmm... are you using the aarch64-darwin branch to build the x86_64 native compiler?

Yes (reason: I’m specially interested in the rpath changes. I used to allow users to relocate the compiler by a massive doinstall/makefile pair that trawls through the binaries adjusting the dylib & executable paths, now I just tell them where to install :) I expect they’ll have to wait to GCC 13?)

iains commented 2 years ago

Of course, could be my configure args. These are what I’ve been using for building gcc branch master on El Capitan and providing to users - I test on Monterey since that’s my normal workhorse.

--with-build-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk --with-sysroot= --with-specs=%{!sysroot=*:--sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk}

Unless you have a local patch to fix it, this is not likely to work (because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885, which is even more acute for Ada).
TBH, --disable-bootstrap is not ideal for a release compiler .. if you already have a 12.0.1 bootstrap and you're using that - perhaps, but from 11.2 not really something I'd recommend.

^^ neither of these alter my suspicion about the branch (I do not usually test that branch building x86_64, so on the basis of "if it ain't tested, it's broke" .. that would be by starting point).

iains commented 2 years ago

hmmm... are you using the aarch64-darwin branch to build the x86_64 native compiler?

Yes (reason: I’m specially interested in the rpath changes. I used to allow users to relocate the compiler by a massive doinstall/makefile pair that trawls through the binaries adjusting the dylib & executable paths, now I just tell them where to install :) I expect they’ll have to wait to GCC 13?)

Well, let's see - I did post the patches, but have not been able to address review comments yet ($dayjob is extra busy at the moment).

iains commented 2 years ago

I think I spotted the goof (or rebase error on my part) .. will try to fix it tomorrow.
using --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk (assuming you made a command line tools install too) a) avoids the bug b) works immediately for users with CLI installed c) makes no difference to users using xcrun or SDKROOT or --sysroot=

(those things override the built-in sys root).

simonjwright commented 2 years ago

--with-build-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk --with-sysroot= --with-specs=%{!sysroot=*:--sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk}

Unless you have a local patch to fix it, this is not likely to work (because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885, which is even more acute for Ada).

AdaCore used this scheme for their Community editions from 2019 (based on GCC 8.3.1). It has the disadvantage of removing /usr/local from consideration. I built GCC 11.1, 11.2 and now 12.0.1 all on darwin15.

TBH, --disable-bootstrap is not ideal for a release compiler .. if you already have a 12.0.1 bootstrap and you're using that - perhaps, but from 11.2 not really something I'd recommend.

My release builds are done with --enable-bootstrap, but for this one I was just doing a preliminary build.

iains commented 2 years ago

the problem was that the default init for STACK_USE_CUMULATIVE_ARGS_INIT had gone missing from the case of non-aarch64-darwin2*.. either I omitted it in the first place or missed that it had been omitted in a rebase ...

... should be fixed by https://github.com/iains/gcc-darwin-arm64/commit/1628ce542eb0697594f490fc24b9adfd3ebc3519

I bootstrapped x86_64 on Darwin20 with the aarch64 branch (and on Darwin21 natively - test results in the usual place).

simonjwright commented 2 years ago

Built successfully! thanks!

I ran the ACATS 4.1 grading tests against this compiler and one built from GCC trunk, identical results.

As to the rpath change, Bring It On!

iains / gcc-darwin-arm64

options.cc fails to compile #82