On 2/5/19 11:40 AM, Jakub Jelinek wrote:
On Tue, Feb 05, 2019 at 11:16:04AM -0500, Jason Merrill wrote:
--- gcc/cp/optimize.c.jj 2019-01-21 23:32:43.000000000 +0100
+++ gcc/cp/optimize.c 2019-02-04 16:40:21.354179933 +0100
@@ -417,6 +417,12 @@ maybe_thunk_body (tree fn, bool force)
gcc_assert (clone_parm);
DECL_ABSTRACT_ORIGIN (clone_parm) = NULL;
args[parmno] = clone_parm;
+ /* Clear TREE_ADDRESSABLE on arguments with non-aggregate
+ types, the thunk will not take addresses of those
+ arguments, will just pass them through to another
+ call. */
+ if (!AGGREGATE_TYPE_P (TREE_TYPE (clone_parm)))
+ TREE_ADDRESSABLE (clone_parm) = 0;
We probably want to do this in maybe_add_lambda_conv_op, as well (in the
loop over fn_args that sets DECL_CONTEXT).
Like below?
I notice that use_thunk clears TREE_ADDRESSABLE unconditionally, is it
important to handle aggregates differently here?
No, I was just trying to be too careful. If use_thunk does that
unconditionally, I think we can as well.
use_thunk also clears DECL_RTL and DECL_HAS_VALUE_EXPR_P, I don't know if
that's important.
I can't imagine how DECL_RTL could be set (these days) and have no idea why
DECL_VALUE_EXPR would be used either.
I'll bootstrap/regtest following patch then:
2019-02-05 Jakub Jelinek <ja...@redhat.com>
PR c++/89187
* optimize.c (maybe_thunk_body): Clear TREE_ADDRESSABLE on
PARM_DECLs of the thunk.
* lambda.c (maybe_add_lambda_conv_op): Likewise.
OK.
Jason
