From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2928 invoked by alias); 7 Mar 2005 16:05:57 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 2836 invoked by alias); 7 Mar 2005 16:05:50 -0000 Date: Mon, 07 Mar 2005 16:05:00 -0000 Message-ID: <20050307160550.2835.qmail@sourceware.org> From: "mark at codesourcery dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050220111234.20103.falk@debian.org> References: <20050220111234.20103.falk@debian.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer X-Bugzilla-Reason: CC X-SW-Source: 2005-03/txt/msg00898.txt.bz2 List-Id: ------- Additional Comments From mark at codesourcery dot com 2005-03-07 16:05 ------- Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types Alexandre Oliva wrote: >>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. Are you sure that we can use TARGET_EXPR as a type-conversion node? I would think in that case that the INITIAL for the TARGET_EXPR would be a call to the derived class constructor. Hmm. I suppose the type of such a constructor is "void", so it may indeed be the case that there's really no relationship between the types. Good point. > 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. Then we really should do that. We could have COMPOUND_LITERAL_EXPR whose type would be the type in the (syntactic) cast, and whose argument would be the CONSTRUCTOR for the brace-enclosed initializer. We'd create one of these things if the TYPE, or any of the initializers, was dependent. The games that you want to play with type-equality are just too fragile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103