------- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-07 14:44 ------- Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types
On Mar 7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Alexandre Oliva wrote: >>> This doesn't look quite right. First, we're trying to get rid of >>> tsubst_copy; we should not add new calls. You should do the RECURs >>> here, and then build up the new node. >> I'd have to use build3 (TARGET_EXPR...) or introduce a new call to >> create a target_expr with given slot, initial and cleanup, because >> AFAICT there isn't any that takes a cleanup. > Yes, you should use build3. Ok. >> They don't, and they can't without this piece of code. When we tsubst >> INITIAL, an incomplete array type (T[]), that had been used as the >> type of the slot and the target_expr itself in >> finish_compound_literal(), called while processing a template, >> digest_init() (or something else; I no longer remember exactly) >> completes the array type with the number of entries in the INITIAL >> CONSTRUCTOR. > Then you should tsubst the INITIAL first, and unconditionally copy the > type to the TARGET_EXPR when you use build3. But what if the TARGET_EXPR had been created for different purposes, and did have a different type than that of the initializer? Say, a Base& being bound to a Derived TARGET_EXPR? That's why I'm performing the tests the way I am. > Or, even better, call > the same functions in semantics.c that the parser would call if not in > a template. In other words, call finish_compound_literal again, from > pt.c. That's the overall design: we try to reuse the same semantic > routines again at template instantiation time. Yeah, I know we'd like to do that, but we can't. At that point we have no clue what that TARGET_EXPR or the CONSTRUCTOR in its initial came from. We'd have to create a new tree node type for compound literals to be able to call finish_compound_literal at that point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
