Patchwork [C++,Patch/RFC] PR 57092

login
register
mail settings
Submitter Paolo Carlini
Date April 29, 2013, 9:05 a.m.
Message ID <517E37C7.7000001@oracle.com>
Download mbox | patch
Permalink /patch/240344/
State New
Headers show

Comments

Paolo Carlini - April 29, 2013, 9:05 a.m.
Hi,

in this 4.8/4.9 Regression, finish_decltype_type doesn't handle 
ADDR_EXPR. In 4.7, finish_decltype_type deals with a TEMPLATE_PARM_INDEX 
and the testcase compiles fine, but it's quite easy - see c++/52282 - to 
trigger the same ICE there too (it would be nice to make progress on the 
latter too).

The patchlet below passes testing, not sure whether there is something 
deeper about this issue.

Thanks,
Paolo.

/////////////////
Jason Merrill - April 29, 2013, 2:48 p.m.
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
Paolo Carlini - April 30, 2013, 12:03 p.m.
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.
Jason Merrill - April 30, 2013, 1:14 p.m.
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
Paolo Carlini - April 30, 2013, 3:59 p.m.
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.
Jason Merrill - April 30, 2013, 6:57 p.m.
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

Patch

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;