Re: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01404.html
Do you have test cases for this?
Changing can_throw_internal/external to depend on whether or not future
inlining is possible looks *very* wrong to me. Surely the only thing
that matters for new code that might appear "below" this position in the
tree is whether or not it might throw, and the only thing that changes
with inlining is increased knowledge of whether and how it throws.
The only thing I can imagine is that somehow an inline function was
incorrectly marked as nothrow, and then it was inlined exposing the
throw (i.e. resx) which then led the problem you report.
On the trans-mem branch this is causing me problems. I'm replacing a
direct function call with an indirect function call. Neither can be
inlined, but inlinable_call_p thinks that it's a possibility for the
indirect function call. With your logic, this magically changes a
statement from !can_throw_internal to can_throw_internal. Which then of
course results in a verify_cfg abort.
r~
