Open fxcoudert opened 2 years ago
$ ~/aarch64-apple-darwin21/gcc-12-0-1/bin/g++ --version
g++ (GCC) 12.0.1 20220226 (experimental) [remotes/origin/master-wip-apple-si revision r12-7490-g1628ce542eb0]
$ ~/aarch64-apple-darwin21/gcc-12-0-1/bin/g++ hb-96230.C -std=c++17 -o t
bash-3.2$ ./t
bad any_cast
So this one, at least, is fixed on master - does it work for x86_64 on the 11 branch?
There is something weird here, because it's still not fixed on the Homebrew version of GCC 13.1.0:
$ clang++ -std=c++17 a.cpp && ./a.out
bad any cast
$ g++-13 -std=c++17 a.cpp && ./a.out
terminate called after throwing an instance of 'std::bad_any_cast'
zsh: abort ./a.out
$ g++-13 -v
Using built-in specs.
COLLECT_GCC=g++-13
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/13.1.0/bin/../libexec/gcc/aarch64-apple-darwin22/13/lto-wrapper
Target: aarch64-apple-darwin22
Configured with: ../configure --prefix=/opt/homebrew/opt/gcc --libdir=/opt/homebrew/opt/gcc/lib/gcc/current --disable-nls --enable-checking=release --with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-13 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 13.1.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --with-system-zlib --build=aarch64-apple-darwin22 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Homebrew GCC 13.1.0)
which is the same as gcc-13-1-darwin
from https://github.com/iains/gcc-13-branch/
I'll have to investigate more to understand why I'm still seeing this, and you're not.
which is the same as
gcc-13-1-darwin
from https://github.com/iains/gcc-13-branch/ I'll have to investigate more to understand why I'm still seeing this, and you're not.
I am seeing it (so the fix has somehow been undone, or was a spurious result - in light of the ABI comment below spurious results are feasible)
$ /opt/iains/aarch64-apple-darwin21/gcc-13-2Dr0/bin/g++ -std=c++17 a.cpp && ./a.out
terminate called after throwing an instance of 'std::bad_any_cast'
Abort trap: 6
$ /opt/iains/aarch64-apple-darwin21/gcc-13-1Dr1/bin/g++ -std=c++17 a.cpp && ./a.out
terminate called after throwing an instance of 'std::bad_any_cast'
Abort trap: 6
$ /opt/iains/aarch64-apple-darwin21/gcc-12-3Dr2/bin/g++ -std=c++17 a.cpp && ./a.out
Bus error: 10
$ /opt/iains/aarch64-apple-darwin21/gcc-12-2Dr1/bin/g++ -std=c++17 a.cpp && ./a.out
Bus error: 10
$ /opt/iains/aarch64-apple-darwin21/gcc-11-4Dr0/bin/g++ -std=c++17 a.cpp && ./a.out
Bus error: 10
Possibly (even likely) related : I found out (this week!!) that Arm64 Darwin actually has a different ABI for typeinfo
from any other target ... typeinfo
is used to implement dynamic casts...
edit: and, of course, catch clauses.
As it happens, I've been working on trying to build libstdc++
on top of c++abi
to try and resolve some of the potential ODR issues we have with mixed library use. This turns out to be quite heavy lifting.
edit: I hope to have a non-polished version of this over the weekend, so I will try this specific case to see if it is typeinfo
confusion that is the issue.
the possible arm64 ABI issue theory is strengthened when finding that the same test works OK on all the same versions for x86_64 (of course, it could also be some other aspect of the Arm64 port 'greenness'.
Initial indications are that the reworked libstdc++ does solve the problem on arm64 (and x86_64 continues to work). However; there is a way to go to polish this up and it's pretty invasive to libstdc++ (so we will have to see if upstream finds it useful).
I don't have the latest build available at the moment, and can't build it (I'm traveling), and this was reported and confirmed on the GCC 11 backport (original report at https://github.com/Homebrew/homebrew-core/issues/96230).