From patchwork Fri Oct 15 15:44:26 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Require canonical type comparison for typedefs again. Date: Fri, 15 Oct 2010 05:44:26 -0000 From: Dodji Seketeli X-Patchwork-Id: 67978 Message-Id: To: Paolo Carlini Cc: Jason Merrill , "H.J. Lu" , GCC Patches Hello Paolo, Jason, I am replying to both of your messages in below. Paolo Carlini writes: [...] >> diff --git a/gcc/testsuite/g++.dg/template/typedef36.C b/gcc/testsuite/g++.dg/template/typedef36.C >> new file mode 100644 >> index 0000000..f6155c1 >> --- /dev/null >> +++ b/gcc/testsuite/g++.dg/template/typedef36.C >> @@ -0,0 +1,23 @@ >> +// Origin: PR c++/45606 >> +// { dg-do compile } >> + >> +#include [...] > > Once again, if, thanks to the analysis you did to fix the problem, you > are able to quickly figure out a shorter testcase, not including the > entire , I think it would be good. You are right. Sorry for not having done it before. It is now done in the udpated patch below. Jason Merrill writes: [...] >> -/* Contains canonical template parameter types. The vector is indexed by >> - the TEMPLATE_TYPE_IDX of the template parameter. Each element is a >> - TREE_LIST, whose TREE_VALUEs contain the canonical template >> - parameters of various types and levels. */ >> +/* Contains canonical template parameter types. The vector is indexed >> + by the TEMPLATE_TYPE_IDX of the template parameter. Each element is >> + a TREE_LIST, whose TREE_PURPOSE is a INT_CST tree representing a >> + total size of the template parameter list a given template >> + parameter would belong too, and whose TREE_VALUEs contain the >> + canonical template parameters of various types and levels, >> + belonging to a set of template parameters which size is >> + TREE_PURPOSE. */ > > We don't really need to change the representation this way, do we? We > can just let structural_comptypes verify that the total parms # > matches. Same with the changes to canonical_type_parameter. Done. > >> + if (TREE_PURPOSE (cur)) >> + { >> + /* So the current template type parameter has a default >> + argument. Substitute the so far fixed-up template >> + parms into it. */ >> + tree default_arg = TREE_PURPOSE (cur); >> + >> + if (TYPE_P (default_arg) >> + && !dependent_type_p (default_arg)) >> + continue; >> + >> + arglist = current_template_args (); > > Why do we need to get current_template_args() again here? > I wonder why myself. Thanks for catching this. I removed it. >> + ++cp_unevaluated_operand; >> + TREE_PURPOSE (cur) = >> + tsubst_expr (default_arg, arglist, >> + tf_none, default_arg, false); >> + --cp_unevaluated_operand; > > tsubst (default_arg, arglist, tf_warning_or_error, parm); > > And don't mess with cp_unevaluated_operand. > Done. >> + /* Now we need to substitute the template parm types that >> + have been fixed up so far into the non-type template >> + parms of this template template parm. E.g, consider this: > > This needs to be recursive, in case the template template parm has its > own template template parms. > > template class V> class W> > class A; Oops, done now. >> + ++cp_unevaluated_operand; >> + substed_parm = tsubst_template_parm (parameter, targs, tf_none); >> + --cp_unevaluated_operand; > > Still shouldn't be messing with cp_unevaluated_operand. And we should > use tf_warning_or_error. Done. > > Also, don't we need to handle default template template arguments? > I am not sure about this but can a default template template argument depend on the template parms of the current template being declared? e.g, in: template struct C { }; template class W = C> struct S { }; Here, the template parms of C haven't been created in the template parm list of S. Furthermore, couldn't tsubsting U into C would wrongly remplace the template parm T of C with U? I said wrongly because now with this patch T and U are different types. > template