| Message ID | 517E37C7.7000001@oracle.com |
|---|---|
| State | New |
| Headers | show |
On 04/29/2013 05:05 AM, Paolo Carlini wrote: > in this 4.8/4.9 Regression, finish_decltype_type doesn't handle > ADDR_EXPR. Hmm...we're seeing the regression because previously finish_decltype_type would have just returned the type of the template parameter so it wouldn't ever see the ADDR_EXPR at instantiation time. But we want to form a DECLTYPE_TYPE so that the mangling is correct. Perhaps the right solution is to handle this case specially in tsubst/DECLTYPE_TYPE: If id is true and the original expr is a TEMPLATE_PARM_INDEX, just instantiate the type of the template parm rather than its value. Jason
Hi, On 04/29/2013 04:48 PM, Jason Merrill wrote: > On 04/29/2013 05:05 AM, Paolo Carlini wrote: >> in this 4.8/4.9 Regression, finish_decltype_type doesn't handle >> ADDR_EXPR. > > Hmm...we're seeing the regression because previously > finish_decltype_type would have just returned the type of the template > parameter so it wouldn't ever see the ADDR_EXPR at instantiation time. > But we want to form a DECLTYPE_TYPE so that the mangling is correct. > Perhaps the right solution is to handle this case specially in > tsubst/DECLTYPE_TYPE: If id is true and the original expr is a > TEMPLATE_PARM_INDEX, just instantiate the type of the template parm > rather than its value. thanks for your feedback. Are we sure that tsubst_copy_and_build, as called by tsubst/DECLTYPE_TYPE, can't return an ADDR_EXPR in other cases besides TEMPLATE_PARM_INDEX as input? I'm wondering if handling the additional TREE_CODE in finish_decltype_type isn't overall preferable (assuming we wouldn't end up soon handling all sorts of *_EXPR ;) Paolo.
On 04/30/2013 08:03 AM, Paolo Carlini wrote: > I'm wondering if handling the > additional TREE_CODE in finish_decltype_type isn't overall preferable > (assuming we wouldn't end up soon handling all sorts of *_EXPR ;) That's exactly the problem; it wouldn't stop with ADDR_EXPR, we would need to handle any form of expression that could be a template non-type argument. Jason
On 04/30/2013 03:14 PM, Jason Merrill wrote: > On 04/30/2013 08:03 AM, Paolo Carlini wrote: >> I'm wondering if handling the >> additional TREE_CODE in finish_decltype_type isn't overall preferable >> (assuming we wouldn't end up soon handling all sorts of *_EXPR ;) > > That's exactly the problem; it wouldn't stop with ADDR_EXPR, we would > need to handle any form of expression that could be a template > non-type argument. Ok. Currently, in some cases (see, eg, template/canon-type-9.C) we have that id is true and DECLTYPE_TYPE_EXPR (t) is a TEMPLATE_PARM_INDEX but the tsubst_copy_and_build call returns a TEMPLATE_PARM_INDEX again, not an ADDR_EXPR, not an expression, and inside finish_decltype_type the instantiation_dependent_expression_p returns true. Shall we also additionally check something like EXPR_P (type) in the special casing? And then, is just type = TREE_TYPE (type) instead of calling finish_decltype_type enough? Too many questions, I know, if you feel like just working on this issue and handle yourself the tricky details I'm still missing, just let me know... Thanks, Paolo.
On 04/30/2013 11:59 AM, Paolo Carlini wrote: > Currently, in some cases (see, eg, template/canon-type-9.C) we have that > id is true and DECLTYPE_TYPE_EXPR (t) is a TEMPLATE_PARM_INDEX but the > tsubst_copy_and_build call returns a TEMPLATE_PARM_INDEX again, not an > ADDR_EXPR, not an expression Good point, this can happen for partial instantiations, when processing_template_decl is still true. We want to keep the DECLTYPE_TYPE around until the expression instantiates to something non-instantiation-dependent. Hmm. Maybe the right answer is to just add a default: case to finish_decltype_type and trust that it will be right. Jason
Index: cp/semantics.c =================================================================== --- cp/semantics.c (revision 198381) +++ cp/semantics.c (working copy) @@ -5389,6 +5389,7 @@ finish_decltype_type (tree expr, bool id_expressio case PARM_DECL: case RESULT_DECL: case TEMPLATE_PARM_INDEX: + case ADDR_EXPR: expr = mark_type_use (expr); type = TREE_TYPE (expr); break; Index: testsuite/g++.dg/cpp0x/decltype53.C =================================================================== --- testsuite/g++.dg/cpp0x/decltype53.C (revision 0) +++ testsuite/g++.dg/cpp0x/decltype53.C (working copy) @@ -0,0 +1,11 @@ +// PR c++/57092 +// { dg-do compile { target c++11 } } + +template <void (*F)(int)> +class B { + decltype(F) v; +}; + +void foo(int) {} + +B<foo> o;