https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68771
--- Comment #22 from Daniel Vollmer <zerolo at gmail dot com> --- (In reply to Iain Sandoe from comment #21) > > I rebuilt 7.4.0 locally just now (so in 10.14.4), and now I can no longer > > reproduce the problem. I'm not sure what could cause the difference, > > though... > > that's always the question - even if it involves a bisection to find it. There's nothing I can think of bisecting -- I assume it's an interaction / ABI problem between 10.14.2 and 10.14.4 (or .3). > > > (Also, I had to patch a system header for compiling g++-7.4.0 in > > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/ucred.h > > in 10.14.4 to not use _Atomic in C++ mode, as seemingly only clang > > understands that). > > That seems rather worrying.. editing system headers is not a good plan. > There's a mechanism for the compiler to use if such tricks prove necessary > (fix-includes). I've reported the bug to Apple, the Command-Line Tools (which include these headers) from 10.14.3 and older were fine (as they didn't include the use of _Atomic in C++ mode), but I don't think this has anything to do with this issue. > So to try and get some sync .. when you bootstrap GCC, what compiler do you > use for the bootstrap - and what as/ld etc? For the compilation just (which is the one where no problem occurred), I used Xcode 10.2 which is > clang++ -v Apple LLVM version 10.0.1 (clang-1001.0.46.3) Target: x86_64-apple-darwin18.5.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > ld -v @(#)PROGRAM:ld PROJECT:ld64-450.3 BUILD 18:01:43 Mar 13 2019 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em LTO support using: LLVM version 10.0.1, (clang-1001.0.46.3) (static support for 22, runtime is 22) TAPI support using: Apple TAPI version 10.0.1 (tapi-1001.0.4.1) > as -v Apple LLVM version 10.0.1 (clang-1001.0.46.3) Target: x86_64-apple-darwin18.5.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1as -triple x86_64-apple-macosx10.14.0 -filetype obj -main-file-name - -target-cpu penryn -fdebug-compilation-dir /Users/maven/Development/bugs/multiple_threads_profile -dwarf-debug-producer Apple LLVM version 10.0.1 (clang-1001.0.46.3) -dwarf-version=4 -mrelocation-model pic -o a.out - > NOTE: There have been salient patches post 7.4.0 that could affect things - > but, rather than build some arbitrary version of 7.4.1, I'd next suggest > seeing if the issue repeats on 8.3. > > My current feeling is that 8.3 is in pretty reasonable shape on Darwin (I > have a bunch of pending patches that ought to make things more robust - will > push a branch in due course). I've tried this same reproducer using g++-8.3.0, also pre-built (bottled) by homebrew, on darwin18.2.0 (so the same OS version but not necessarily bootstrapping compiler as the failing 7.4.0), and that version also seems to work fine.
