This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

can_throw_internal affected by inlining?


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~



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]