#include <exception> std::exception_ptr p; void f() { try { throw 1; } catch(char) { std::rethrow_exception(p); } } int main() { for (int i = 0; i != 100000; ++i) try { f(); } catch (...) { } } Compiled with -fsanitize=address (and at -O0 through -O3), this is roughly 30x slower under gcc 13 than under gcc 12 (4.7s vs 0.15s on my Core i7 3 GHz). Note that the std::rethrow_exception() is not called, but is still essential to exhibit the bug. Also `f` needs to be a separate function (and not `static`). At low optimization levels it can be an iife.
Motivation is https://github.com/boostorg/exception/blob/b039b4ea18ef752d0c1684b3f715ce493b778060/include/boost/exception/detail/exception_ptr.hpp#L550 ; the half-reduced code is: #include <boost/exception_ptr.hpp> struct S {}; int main() { auto ep = boost::copy_exception(S()); for (int i = 0; i != 100000; ++i) try { boost::rethrow_exception(ep); } catch (...) {} }
The code generation does not look any difference ... So I am suspecting this was a library change. Which might mean it is an issue in LLVM too ...
(In reply to Andrew Pinski from comment #2) > Which might mean it is an issue in LLVM too ... Yes the same runtime regression shows up between clang 15 and clang 16. This should reported upstream to them too.
Confirmed.
(In reply to Andrew Pinski from comment #3) > (In reply to Andrew Pinski from comment #2) > > Which might mean it is an issue in LLVM too ... > > Yes the same runtime regression shows up between clang 15 and clang 16. This > should reported upstream to them too. What is interesting is that with -stdlib=libc++ the regression for clang/LLVM shows up between their 14 and 15 releases. Anyways this should be filed upstream ...
Thanks, filed https://github.com/llvm/llvm-project/issues/64190 .
*** Bug 112981 has been marked as a duplicate of this bug. ***
GCC 13.3 is being released, retargeting bugs to GCC 13.4.