This is the mail archive of the
mailing list for the GCC project.
Re: [C++ Patch/RFC] PR 57092
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 30 Apr 2013 14:03:52 +0200
- Subject: Re: [C++ Patch/RFC] PR 57092
- References: <517E37C7 dot 7000001 at oracle dot com> <517E883B dot 7020702 at redhat dot com>
On 04/29/2013 04:48 PM, Jason Merrill wrote:
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 ;)
On 04/29/2013 05:05 AM, Paolo Carlini wrote:
in this 4.8/4.9 Regression, finish_decltype_type doesn't handle
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.