From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13713 invoked by alias); 7 Mar 2005 21:58:37 -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 13653 invoked by alias); 7 Mar 2005 21:58:28 -0000 Date: Mon, 07 Mar 2005 21:58:00 -0000 Message-ID: <20050307215828.13652.qmail@sourceware.org> From: "aoliva at redhat 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/msg00949.txt.bz2 List-Id: ------- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-07 21:58 ------- Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types On Mar 7, 2005, Mark Mitchell wrote: >>> The games that you want to play with type-equality are just too fragile. >> I still don't see why. > First, you're using "==". As I've told you, that's incredibly > fragile. Not for the purpose I've been trying to describe. The condition I want to maintain is that, if the TARGET_EXPR had the type of its INITIAL before template substitution, then it must have the type of its INITIAL after template substitution, because whatever transformations the INITIAL type might undergo won't be applied to the TARGET_EXPR. It's that simple, so it should be quite obvious that `==' is what I'm looking for. It's not just same_type_p; if the types of the TARGET_EXPR was not taken from the INITIAL, then I don't care how it evolves. > You're depending on a very non-local property that in the > case that you're interested in, the types will always be ==. No, I'm only guaranteeing that, if this property held before template substitution, it still holds afterwards. If it didn't hold before, it still won't hold afterwards. It's much simpler than what you describe. > But, minor changes elsewhere might make them same_type_p, but not > ==, in some cases. If that's fine for those cases, it will remain so after template substitution. Sounds *exactly* like what I want. > Second, you're applying a non-uniform manipulation on the types of the > TARGET_EXPR, based on a non-local property about how TARGET_EXPRs are > created, without actually checking that the condition you're > interested in (incomplete array types) applies. Huh?!? No, I'm not. Read the code again. It goes like this: if the decl type and the initializer type were the same before, make them the same after if the target_expr type and the decl type were the same before, make them the same after and that's it. It's that simple. Nothing non-uniform about it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103