From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-18166-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 5994 invoked by alias); 30 Apr 2002 12:36:04 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 5962 invoked by uid 71); 30 Apr 2002 12:36:02 -0000
Date: Tue, 30 Apr 2002 05:36:00 -0000
Message-ID: <20020430123602.5961.qmail@sources.redhat.com>
To: jason@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Jason Merrill <jason@redhat.com>
Subject: Re: debug/6436: dwarf2out ICE with typedef using attributes
Reply-To: Jason Merrill <jason@redhat.com>
X-SW-Source: 2002-04/txt/msg01629.txt.bz2
List-Id: <gcc-prs.sourceware.org>

The following reply was made to PR debug/6436; it has been noted by GNATS.

From: Jason Merrill <jason@redhat.com>
To: Daniel Berlin <dberlin@dberlin.org>
Cc: jakub@gcc.gnu.org, <gcc-bugs@gcc.gnu.org>, <meissner@suse.de>,
	<gcc-gnats@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>,
	Mark Mitchell <mark@codesourcery.com>,
	Richard Sandiford <rsandifo@redhat.com>
Subject: Re: debug/6436: dwarf2out ICE with typedef using attributes
Date: Tue, 30 Apr 2002 11:01:51 +0100

 >>>>> "Daniel" == Daniel Berlin <dberlin@dberlin.org> writes:
 
 > For C++, we output two *named* types first, ._0, which is the A *without* 
 > alignment, then ._1, which is the A *with* alignment.
 
 Actually, ._1 is B.  The C++ standard says
 
   If the typedef declaration defines an unnamed  class  (or  enum),  the
   first  typedef-name  declared by the declaration to be that class type
   (or enum type) is used to denote the class type  (or  enum  type)  for
   linkage purposes only.
 
 So we set TYPE_NAME for the type to be the typedef, rather than the funny
 internal name.  For B this is fine, because the type of the name B is the
 struct itself.  For A we have a problem: the type of the name A is an
 attribute-variant of the anonymous struct, but we set the struct's name
 anyway.  So
 
   TREE_TYPE (TYPE_NAME (type)) != type
 
 but
 
   DECL_ORIGINAL_TYPE (TYPE_NAME (type)) == type
 
 One fix would be to not give the name 'A' to the anonymous struct.
 However, that would mean that we couldn't use the type in a mangled
 context, and I suspect that there is code out there that relies on this
 sort of pattern, though I suppose it's easy enough to fix affected code by
 adding an "A" after the "struct" tag.
 
 Jason