Message ID | 1321907252.12248.128.camel@triegel.csb |
---|---|
State | New |
Headers | show |
On 11/21/2011 12:27 PM, Torvald Riegel wrote: > voidify_wrapper_expr didn't handle MUST_NOT_THROW_EXPR before, but was > used by the C++ side gimplify function for MUST_NOT_THROW_EXPR. Handle > it like other wrappers which have the inner part in operand 0. > > OK for trunk? Not ok. This is a c++ specific name used in a non-c++ file. You should have seen a bootstrap failure. r~
On Mon, 2011-11-21 at 12:30 -0800, Richard Henderson wrote: > On 11/21/2011 12:27 PM, Torvald Riegel wrote: > > voidify_wrapper_expr didn't handle MUST_NOT_THROW_EXPR before, but was > > used by the C++ side gimplify function for MUST_NOT_THROW_EXPR. Handle > > it like other wrappers which have the inner part in operand 0. > > > > OK for trunk? > > Not ok. This is a c++ specific name used in a non-c++ file. > You should have seen a bootstrap failure. I did not, interestingly. I also *assumed* that this wouldn't work and therefore sent you and Jason an email recentl asking how to best handle this. But then I just gave it a try and it seemed to do the job. So, again, what is the alternative? Quoting my last email: It still fails when combined with transaction expressions (noexcept-4.C and noexcept-1.C) because gimplify_must_not_throw_expr() calls voidify_wrapper_expr() on a MUST_NOT_THROW_EXPR which it doesn't know to be a wrapper. What's the cleanest way to solve that? Adding handling of MUST_NOT_THROW_EXPR inside voidify_... will include C++ stuff there, right? Or should there be a C++ version of voidify_...? Or something else? Torvald
On 11/21/2011 01:39 PM, Torvald Riegel wrote: > It still fails when combined > with transaction expressions (noexcept-4.C and noexcept-1.C) because > gimplify_must_not_throw_expr() calls voidify_wrapper_expr() on a > MUST_NOT_THROW_EXPR which it doesn't know to be a wrapper. What's the > cleanest way to solve that? Adding handling of MUST_NOT_THROW_EXPR > inside voidify_... will include C++ stuff there, right? Or should there > be a C++ version of voidify_...? Or something else? What's happening below gimplify_must_not_throw_expr? That *ought* to be recursing into voidify_wrapper_expr and doing the right thing. r~
On Mon, 2011-11-21 at 13:45 -0800, Richard Henderson wrote: > On 11/21/2011 01:39 PM, Torvald Riegel wrote: > > It still fails when combined > > with transaction expressions (noexcept-4.C and noexcept-1.C) because > > gimplify_must_not_throw_expr() calls voidify_wrapper_expr() on a > > MUST_NOT_THROW_EXPR which it doesn't know to be a wrapper. What's the > > cleanest way to solve that? Adding handling of MUST_NOT_THROW_EXPR > > inside voidify_... will include C++ stuff there, right? Or should there > > be a C++ version of voidify_...? Or something else? > > What's happening below gimplify_must_not_throw_expr? > > That *ought* to be recursing into voidify_wrapper_expr and > doing the right thing. gimplify_must_not_throw_expr does call voidify_wrapper_expr, with the assumption that the latter understands that MNTE is a wrapper, and will change the code contained in the wrapper (so, change the MNTE itself). I thought about changing voidify_wrapper_expr so that its first argument is a pointer to a tree, so that one can voidify the contained/inner stuff even when the caller has already skipped a wrapper (MNTE in our case). But this didn't seem to be clearer either. Torvald
diff --git a/gcc/gimplify.c b/gcc/gimplify.c index cfe6696..2cd48de 100644 --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -1050,6 +1050,7 @@ voidify_wrapper_expr (tree wrapper, tree temp) case CLEANUP_POINT_EXPR: case TRY_FINALLY_EXPR: case TRY_CATCH_EXPR: + case MUST_NOT_THROW_EXPR: TREE_SIDE_EFFECTS (*p) = 1; TREE_TYPE (*p) = void_type_node; p = &TREE_OPERAND (*p, 0);