This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR c++/42225
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Dodji Seketeli <dodji at redhat dot com>
- Cc: Jason Merrill <jason at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 15 Feb 2010 21:06:45 -0800
- Subject: Re: [PATCH] PR c++/42225
- References: <20091211121043.GG3009@adjoa.torimasen.com> <20091213205638.GC14933@adjoa.torimasen.com> <4B268242.firstname.lastname@example.org> <20091214212823.GI14933@adjoa.torimasen.com> <4B26B819.email@example.com> <20091215101001.GJ14933@adjoa.torimasen.com> <4B27EB08.firstname.lastname@example.org> <20091217142113.GK14933@adjoa.torimasen.com> <4B2A6E90.email@example.com> <20091218201040.GL14933@adjoa.torimasen.com>
On Fri, Dec 18, 2009 at 12:10 PM, Dodji Seketeli <firstname.lastname@example.org> wrote:
> On Thu, Dec 17, 2009 at 12:46:56PM -0500, Jason Merrill wrote:
>> On 12/17/2009 09:21 AM, Dodji Seketeli wrote:
>>> Right now that DECL_CONTEXT is not set for template type parms. So the
>>> patch below sets it.
>> Once we do that, perhaps structural_comptypes can compare the template
>> parms from the context of template type parms, so we don't need special
>> handling for typedefs at all?
> The problem I figured was that for a template type parm that is not a
> typedef, having structural_comptypes calling comp_template_parms with
> the list of template parms it belongs to can result in an endless
> recursion. So I think (but I might be missing something) that to compare
> two template type parms that are not typedefs, comparing their position
> - like what is done today - is the way to go.
> The comparison of the template parms of the context would be used only
> when typedefs are involved.
> However, I tried to integrate the whole thing a bit better in
> structural_comptypes, in the spirit you are mentioning, even though
> there is still a special case for typedefs. The gain is that now we only
> care about TEMPLATE_TYPE_PARMs typedefs. Not dependent typedefs in the
> general sense.
> Also, I changed cp_set_underlying_type to require structural type
> equality only for TEMPLATE_TYPE_PARMs as doing it for "general"
> dependent typedefs is not necessary anymore.
> Tested on x86_64-unknown-linux-gnu.
> ? ? ? ?Dodji
> commit fd11ca8110acdcfe93d561bf864ea394b7316a9c
> Author: Dodji Seketeli <email@example.com>
> Date: ? Fri Dec 11 23:03:26 2009 +0100
> ? ?Fix PR c++/42225, take 2
> ? ?gcc/cp/ChangeLog:
> ? ? ? ?* pt.c (push_template_decl_real): Set DECL_CONTEXT of template type parms
> ? ? ? ?to their containing template decl.
> ? ? ? ?* typeck.c (comp_template_parms_position): Split this from
> ? ? ? ?structural_comptypes.
> ? ? ? ?(incompatible_template_type_parms_p): Renamed
> ? ? ? ?incompatible_dependent_typedefs_p into this. Change the function to
> ? ? ? ?handle comparison between TEMPLATE_TYPE_PARMs only.
> ? ? ? ?(structural_comptypes): Use comp_template_parms_position in
> ? ? ? ?TEMPLATE_TEMPLATE_PARM and BOUND_TEMPLATE_TEMPLATE_PARM case.
> ? ? ? ?Use incompatible_template_type_parms_p in TEMPLATE_TYPE_PARM case.
> ? ? ? ?* mangle.c (decl_mangling_context): Template type parms don't have
> ? ? ? ?a mangling context.
> ? ? ? ?* tree.c (cp_set_underlying_type): Require type structural equality
> ? ? ? ?for TEMPLATE_TYPE_PARMs only.