C++: exception raised by any_cast leads to SIGBUS

[fxcoudert]

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 Homebrew/homebrew-core#96230).

$ cat a.cpp 
#include <iostream>
#include <any>

int main()
{
    std::any a1 = "123.456";
  
    try
    {
      double x = std::any_cast<double>(a1);
      std::cout << x << std::endl;
    }
    catch(std::exception const &e)
    {
      std::cout << e.what() << std::endl;
    }

    return 0;
}
$ clang++ a.cpp -std=c++17 && ./a.out
bad any cast
$ g++-11 a.cpp -std=c++17 && ./a.out 
zsh: bus error  ./a.out

[iains]

$ ~/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?

[fxcoudert]

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.

[iains]

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.

[iains]

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'.

[iains]

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).