> I've looked at the C++ testcase
>
> int foo (int &x)
> {
> try {
> return x;
> }
> catch (...)
> {
> return 0;
> }
> }
>
> which exhibits exactly the behavior you quote - return x is considered
> throwing an exception. The C++ FE doesn't arrange for TREE_THIS_NOTRAP to
> be set here (maybe due to this issue you quote?).
I presume that you compiled with -fnon-call-exceptions? Otherwise, I don't
see how something that isn't a call can throw an exception in C++, it should
be seen at most as possibly trapping, which is less blocking.
> Other than that the patch looks reasonable (I suppose you need
> is_parameter_of only because as we recursively handle the trees
> PARM_DECLs from the destination could already have leaked into
> the tree we recurse into?)
Do you mean that the test on DECL_CONTEXT is superfluous? Possibly indeed,
but with nested functions you can have PARM_DECLs of different origins in a
given function body, although this may be irrelevant for tree-inline.c.
--
Eric Botcazou
