http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #9 from Richard Henderson <rth at gcc dot gnu.org> 2013-01-15 19:13:44 UTC --- Unfortunately, the gdb trace in #c1 isn't enough to see what's actually failing. What *ought* to be happening is that the uninstrumented code path runs, f1 makes two calls into the normal c++ runtime to (1) allocate the memory for the thrown int, and (2) actually throw the exception. Then we reach a cleanup inside f2 that calls _ITM_commitTransactionEH which commits the transaction (which will never fail, since we're in serial mode, since we're running the uninstrumented code path). Then we return from _ITM_cTEH and continue propagation of the exception, reaching main. This is exactly what happens under linux. What needs to happen at this point is a more detailed trace of f1 beginning at the line containing the throw. Given that EH is involved, this might require "display/i $pc" and "stepi" to avoid losing control. At the moment we have no idea even which runtime library is generating the fault.
