After update to macOS Big Sur 11.3 with XCode 12.5 and Apple Clang clang-1205.0.22.9, bootstrap doesn't work any more: Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs Bootstrap comparison failure! gcc/tree-ssa-operands.o differs gcc/tree-ssanames.o differs [...] lib/libz_a-deflate.o differs zlib/libz_a-gzread.o differs zlib/libz_a-inflate.o differs zlib/libz_a-crc32.o differs zlib/libz_a-inftrees.o differs
I just check, with --disable-bootstrap, gcc compiles to the end. Just the checksums of the object files for bootstrap between stage 2 and 3 don't agree.
Confirmed.
(In reply to Dominique d'Humieres from comment #3) > Confirmed. Merci, Dominique. Would you actually advise to compile without bootstrap and start using gcc, or wait until the reason for the bootstrap failure is understood and hopefully fixed?
Does it work when you use STAGE1_CFLAGS="-O0" (I think clang defaults to optimizing?). To rule out compare-debug issues also try --without-build-config
(In reply to Richard Biener from comment #5) > Does it work when you use STAGE1_CFLAGS="-O0" (I think clang defaults to > optimizing?). To rule out compare-debug issues also try > --without-build-config The reason for the fail is that the assembler (clang -cc1as) is assembling branch instructions with differing lengths between the debug and non-debug cases. The code is not actually wrong in either case - it simply looks like branch relaxation has been enabled in one case and not the other. However this is not in response to changed command line options (so it is an internal decision in the assembler, probably as a result of detecting either .loc directives or presence/absence of Lxxxx local labels between branch and its destination.). I am discussing with OSS folks at Apple whether this is an intentional change (i.e to produce better optimised code) or an accidental one. Short-term workarounds: 1. (re-)install xcode 12.4 command line tools and select them for use 2. disable debug comparison in the bootstrap ( --without-build-config )
(In reply to Iain Sandoe from comment #6) > (In reply to Richard Biener from comment #5) > > Does it work when you use STAGE1_CFLAGS="-O0" (I think clang defaults to > > optimizing?). To rule out compare-debug issues also try > > --without-build-config > I am discussing with OSS folks at Apple whether this is an intentional > change (i.e to produce better optimised code) or an accidental one. If the result comes back "we intended to do this" then there are a couple of options. 1) ask them to implement some option to disable this (and we can trigger that option from -gtoggle) Which would mean that the production compiler had the advantage of the additional optimisation - but we could still prove that our code-gen was the same with/without debug. 2) We can implement (1) ourselves using the llas driver I wrote - which drives the LLVM backend, but presents command line options like cctools (i.e. more like GAS). for now I guess we have to wait for a reply,
(In reply to Iain Sandoe from comment #6) > > 1. (re-)install xcode 12.4 command line tools and select them for use > 2. disable debug comparison in the bootstrap ( --without-build-config ) Just to report that --without-build-config did successfully compile and bootstrap.
JFTR the Apple OSS folks comment: "I checked with the clang team — it appears this was an unintentional consequence of an upstream change: https://reviews.llvm.org/D75203. This difference between debug vs non-debug asm has been noticed upstream and the new assembly optimization has been disabled (for now) in https://reviews.llvm.org/D94542 already. You should be able to avoid this issue with clang-1205 by adding in the `-mllvm -x86-pad-for-align=false` flags to the build. I confirmed this resolved the issue for me with the small reproducer. " however, that means we will need to do some configury checks to decide if this fix needs to be applied or not (and maybe that would best be deferred until we see what version of Xcode contains a fix).
Query from someone who I believe just encountered this trying to build 11.2 on macOS 11.5.1 with XCode 12.5: What is the best method to work around this for now? 1. Update to XCode 12.5.1 (which apparently exists, but I don't know if it has the fixes?) 2. Pass in `--without-build-config` to configure (which is how Homebrew does it) 3. Iain's last suggestion about `-mllvm -x86-pad-for-align=false` (I'm not sure where to put that) The easiest for me to try was #2 and it seems to work, but I don't know if that has side-effects for the built compiler. (Of course, our software currently has some issues with GCC 11.1 that I think are still open here on Bugzilla (like #100651), but I thought I'd see if 11.2 fixes them!)
(In reply to Matt Thompson from comment #10) > Query from someone who I believe just encountered this trying to build 11.2 > on macOS 11.5.1 with XCode 12.5: What is the best method to work around this > for now? > > 1. Update to XCode 12.5.1 (which apparently exists, but I don't know if it > has the fixes?) not yet checked - but if someone has time I'd like to know ;) > 2. Pass in `--without-build-config` to configure (which is how Homebrew does > it) the disadvantage of that is that it skips the compare objects stage (because that is what fails) .. but it works, indeed. > 3. Iain's last suggestion about `-mllvm -x86-pad-for-align=false` (I'm not > sure where to put that) We will need configure to detect version(s) of the assembler that fail and to apply this to the 'as' lines where needed - I didn't get to this because it's far from a 5mins job and: a) was hoping for a fix [does anyone know if 12.5.1 fixes?] b) it was easier for me to revert to using command-line-tools 12.4 for X86 (the bug doesn't fire for my experimental work on arm64, so I can use 12.5 there). ... having said that, if we don't see a fix soon and there end up being un-fixable configurations (e.g. versions which don't support a fixed Xcode, then we'll need to do the configury magic). > The easiest for me to try was #2 and it seems to work, but I don't know if > that has side-effects for the built compiler. as noted above - no side effects on the compiler, but a reduction in the testing of the build. > (Of course, our software currently has some issues with GCC 11.1 that I > think are still open here on Bugzilla (like #100651), but I thought I'd see > if 11.2 fixes them!) please CC me on Darwin/macOS bugs -- too many mailing lists ;-) I miss bugs sometimes.
(In reply to Iain Sandoe from comment #11) > > 1. Update to XCode 12.5.1 (which apparently exists, but I don't know if it > > has the fixes?) > > not yet checked - but if someone has time I'd like to know ;) > > > a) was hoping for a fix [does anyone know if 12.5.1 fixes?] > I just checked with XCode 12.5.1, nothing fixed yet, the problem persists.
Just to add, the --disable-bootstrap workaround no longer works with the recently released 11.2.0, as it still fails to build due to jit errors. :info:build Bootstrap comparison failure! :info:build gcc/jit/jit-recording.o differs The same build configuration and workaround worked fine with gcc 11.1.0. See https://build.macports.org/builders/ports-11_x86_64-builder/builds/41670/steps/install-port/logs/stdio for a full build log.
Apologies, typo above. I meant to say the --without-build-config workaround no longer works with 11.2.0
(In reply to Chris Jones from comment #14) > Apologies, typo above. I meant to say the --without-build-config workaround > no longer works with 11.2.0 OK.. I plan to do a Darwin/macOS 11.2 patch set this weekend - I'll see what we can do about that (other than rolling back to Xcode 12.4 on X86_64 macOS).
(In reply to Chris Jones from comment #14) > Apologies, typo above. I meant to say the --without-build-config workaround > no longer works with 11.2.0 Huh. I tried it and it seemed to work for me? Well, I was able to "make" and "make install". I didn't try "make check" is that where it failed for you? For reference, my configure line was: ../gcc-11.2.0/configure --prefix=$HOME/installed/Core/gcc-gfortran/11.2.0 --enable-languages=c,c++,fortran --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --without-build-config |& tee configure.log
Your configuration isn't enabling the jit compiler.
try again with --enable-languages=c,c++,fortran,jit
(In reply to Chris Jones from comment #18) > try again with > > --enable-languages=c,c++,fortran,jit Ahh. I feel dumb. And I've learned that GCC apparently now has a JIT compiler! Time to do some reading and research! :D
I am testing a patch series (expected to push a github copy today if that testing goes OK) including an implementation of comment #9. However, IFF the jit build does not honour --without-build-config, that actually seems like a different bug. I rarely build the jit, but will take a look when time permits.
(In reply to Iain Sandoe from comment #20) > I rarely build the jit, but will take a look when time permits. Actually, currently it seems that the JIT build is quite broken on Darwin; I have some draft patches that fix the build. The testsuite has some additional issues (which I have partial patches for). When all of these are done - there are still a number of testsuite fails for cases including -g (i.e. debug) in the recipe. Those are going to take some more work / understanding to fix. The build fixes are in my "short queue"; the testsuite fixes will most likely need review.
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: https://gcc.gnu.org/g:743b8dd6fd757e997eb060d70fd4ae8e04fb56cd commit r12-2968-g743b8dd6fd757e997eb060d70fd4ae8e04fb56cd Author: Iain Sandoe <iain@sandoe.co.uk> Date: Sat Jul 31 16:29:03 2021 +0100 Darwin, X86, config: Adjust 'as' command lines [PR100340]. Versions of the assembler using clang from XCode 12.5/12.5.1 have a bug which produces different code layout between debug and non-debug input, leading to a compare fail for default configure parameters. This is a workaround fix to disable the optimisation that is responsible for the bug. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> PR target/100340 - Bootstrap fails with Clang 12.0.5 (XCode 12.5) PR target/100340 gcc/ChangeLog: * config.in: Regenerate. * config/i386/darwin.h (EXTRA_ASM_OPTS): New (ASM_SPEC): Pass options to disable branch shortening where needed. * configure: Regenerate. * configure.ac: Detect versions of 'as' that support the optimisation which has the bug.
so fixed on master, but needed on the open branches - so leaving the PR open for now.
(In reply to Iain Sandoe from comment #23) > so fixed on master, but needed on the open branches - so leaving the PR open > for now. Iain, a query: Is the `--without-build-config` flag still needed for XCode 13.0? I'm hoping to have that version on my laptop some time today and I figure I should make a note if I'll need to use it in case I have to rebuild 11.2. (I'm thinking 11.3 if/when it's released would be fine?)
(In reply to Matt Thompson from comment #24) > (In reply to Iain Sandoe from comment #23) > > so fixed on master, but needed on the open branches - so leaving the PR open > > for now. > > Iain, a query: Is the `--without-build-config` flag still needed for XCode > 13.0? I'm hoping to have that version on my laptop some time today and I > figure I should make a note if I'll need to use it in case I have to rebuild > 11.2. (I'm thinking 11.3 if/when it's released would be fine?) I haven't tested Xcode 13 yet - so can't comment. The idea is that it will be fixed on all open branches at their next release (even if using Xcode 12)
Current gcc-11.2 builds with Xcode 13 w/out having to use `--without-build-config`. Exact same setup failed w/ Xcode 12.5.1.
The releases/gcc-11 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: https://gcc.gnu.org/g:8b333df9484c1697f3a80530a47aa90b1859e970 commit r11-9147-g8b333df9484c1697f3a80530a47aa90b1859e970 Author: Iain Sandoe <iain@sandoe.co.uk> Date: Sat Jul 31 16:29:03 2021 +0100 Darwin, X86, config: Adjust 'as' command lines [PR100340]. Versions of the assembler using clang from XCode 12.5/12.5.1 have a bug which produces different code layout between debug and non-debug input, leading to a compare fail for default configure parameters. This is a workaround fix to disable the optimisation that is responsible for the bug. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> PR target/100340 - Bootstrap fails with Clang 12.0.5 (XCode 12.5) PR target/100340 gcc/ChangeLog: * config.in: Regenerate. * config/i386/darwin.h (EXTRA_ASM_OPTS): New (ASM_SPEC): Pass options to disable branch shortening where needed. * configure: Regenerate. * configure.ac: Detect versions of 'as' that support the optimisation which has the bug. (cherry picked from commit 743b8dd6fd757e997eb060d70fd4ae8e04fb56cd)
(In reply to CVS Commits from comment #27) > The releases/gcc-11 branch has been updated by Iain D Sandoe > <iains@gcc.gnu.org>: > > https://gcc.gnu.org/g:8b333df9484c1697f3a80530a47aa90b1859e970 > > commit r11-9147-g8b333df9484c1697f3a80530a47aa90b1859e970 > Author: Iain Sandoe <iain@sandoe.co.uk> > Date: Sat Jul 31 16:29:03 2021 +0100 > > Darwin, X86, config: Adjust 'as' command lines [PR100340]. > > Versions of the assembler using clang from XCode 12.5/12.5.1 > have a bug which produces different code layout between debug and > non-debug input, leading to a compare fail for default configure > parameters. > > This is a workaround fix to disable the optimisation that is > responsible for the bug. > > Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> > > PR target/100340 - Bootstrap fails with Clang 12.0.5 (XCode 12.5) > > PR target/100340 > > gcc/ChangeLog: > > * config.in: Regenerate. > * config/i386/darwin.h (EXTRA_ASM_OPTS): New > (ASM_SPEC): Pass options to disable branch shortening where > needed. > * configure: Regenerate. > * configure.ac: Detect versions of 'as' that support the > optimisation which has the bug. > > (cherry picked from commit 743b8dd6fd757e997eb060d70fd4ae8e04fb56cd) Did this fix it? (asking due to downstream issue https://trac.macports.org/ticket/63312 in MacPorts, btw)
To synchronise things. The same issue is appears on Yosemite (10.10) on MacPort's build bots on gcc10-bootstrap port with backported Iain's patch to as: - https://build.macports.org/builders/ports-10.10_x86_64-builder/builds/180787 - https://trac.macports.org/ticket/65033 Anyway, I can't reproduce it on Yosemite that I have.
(In reply to Kirill A. Korinsky from comment #29) > To synchronise things. > > The same issue is appears on Yosemite (10.10) on MacPort's build bots on > gcc10-bootstrap port with backported Iain's patch to as: > - > https://build.macports.org/builders/ports-10.10_x86_64-builder/builds/180787 > - https://trac.macports.org/ticket/65033 this ^ seems to 404 for me. I am slightly confused - are you saying that someone is using Xcode 12.5 on Yosemite? (I would be amazed if that was a supported configuration). NOTE: there are still back ports queued for GCC-10 (which would appear in 10.4).
Iain, you're right. This is a differnt things vecause it uses xcode 7.2.1.
Unsure about GCC 10/11 status.
(In reply to Richard Biener from comment #32) > Unsure about GCC 10/11 status. was fixed for 11, in my queue for 10.4 (time-willing)
The releases/gcc-10 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: https://gcc.gnu.org/g:8e4e6100d7fdef22e3f3c8475699a32aeb3e60ea commit r10-10776-g8e4e6100d7fdef22e3f3c8475699a32aeb3e60ea Author: Iain Sandoe <iain@sandoe.co.uk> Date: Sat Jul 31 16:29:03 2021 +0100 Darwin, X86, config: Adjust 'as' command lines [PR100340]. Versions of the assembler using clang from XCode 12.5/12.5.1 have a bug which produces different code layout between debug and non-debug input, leading to a compare fail for default configure parameters. This is a workaround fix to disable the optimisation that is responsible for the bug. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> PR target/100340 - Bootstrap fails with Clang 12.0.5 (XCode 12.5) PR target/100340 gcc/ChangeLog: * config.in: Regenerate. * config/i386/darwin.h (EXTRA_ASM_OPTS): New (ASM_SPEC): Pass options to disable branch shortening where needed. * configure: Regenerate. * configure.ac: Detect versions of 'as' that support the optimisation which has the bug. (cherry picked from commit 743b8dd6fd757e997eb060d70fd4ae8e04fb56cd)
so fixed on open branches, needed for 'vendor' versions of closed ones.
Note that the solution to this has caused downstream MacPorts bug 65236: https://trac.macports.org/ticket/65236
(In reply to Eric Gallager from comment #36) > Note that the solution to this has caused downstream MacPorts bug 65236: > https://trac.macports.org/ticket/65236 the macports ticket does not contain enough information to figure out the problem ... I build and test regularly on Darwin9-21 and have used a range of installed Xcode CLT: e.g. here's the latest I have: gcc/as -arch x86_64 -v -mmacosx-version-min=12.0 -mllvm -x86-pad-for-align=false -force_cpusubtype_ALL -o /Volumes/ramdisk/ccuqyehz.o /Volumes/ramdisk/ccN3ilQO.s Apple clang version 13.1.6 (clang-1316.0.21.2.5) Target: x86_64-apple-darwin21.6.0 Thread model: posix InstalledDir: /Users/Shared/XC/13.4/CommandLineTools/usr/bin "/Users/Shared/XC/13.4/CommandLineTools/usr/bin/clang" -cc1as -triple x86_64-apple-macosx12.0.0 -filetype obj -main-file-name ccN3ilQO.s -target-cpu penryn -fdebug-compilation-dir=/scratch/12-mon/gcc-master -dwarf-debug-producer "Apple clang version 13.1.6 (clang-1316.0.21.2.5)" -dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm -x86-pad-for-align=false -mllvm -disable-aligned-alloc-awareness=1 -o /Volumes/ramdisk/ccuqyehz.o /Volumes/ramdisk/ccN3ilQO.s works fine (i.e the assembler is accepting the flag) .. so I am not sure where the problem is arising in the bias stuff. Perhaps, by some strange mechanism, the cctools assembler is being invoked ?