From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27926 invoked by alias); 24 Nov 2001 23:02:13 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 27905 invoked from network); 24 Nov 2001 23:02:12 -0000 Received: from unknown (HELO monkey.daikokuya.demon.co.uk) (158.152.184.26) by sourceware.cygnus.com with SMTP; 24 Nov 2001 23:02:12 -0000 Received: from neil by monkey.daikokuya.demon.co.uk with local (Exim 3.32 #1 (Debian)) id 167lp3-0001I6-00; Sat, 24 Nov 2001 23:02:57 +0000 Date: Thu, 15 Nov 2001 01:44:00 -0000 From: Neil Booth To: Gabriel Dos Reis Cc: Mark Mitchell , "gcc@gcc.gnu.org" Subject: Re: ICE in change_address at emit_rtl.c Message-ID: <20011124230256.B4815@daikokuya.demon.co.uk> References: <72730000.1006640472@warlock.codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2001-11/txt/msg00666.txt.bz2 Gabriel Dos Reis wrote:- > What worries is the alternative he's proposing. My personnal view is > to have ERROR_MARK_XXX for TYPE, DECL and such in order to enhance > the tree type system and maintainability. Changing tack a little now, but still on the topic of violent changes to improve readability 8-) I've often wondered whether we might do better type-wise to actually use separate types, and refer to them as separate types, rather than having every function take an effectively typeless "tree" as input. This alone would help type safety quite a bit. If we used separate types, it would be a good idea, I suspect, to not use macros as accessors as frequently as we do now, but instead to have each member of the tree union have its own names for the common fields. I realise that the macros improve maintainability for moving stuff around, but I think a lot of that problem is caused by extreme overloading of e.g. the bitfields in tree_common whose name doesn't correspond to what they are used for for most types. An illustrative example of what is wrong with the current approach: can you tell me exactly which bit fields in tree_common are used by, say, an IDENTIFIER_NODE across front ends, and which are free, just by looking at the documentation in tree.h? [You have a better chance now because I updated the documentation in tree.h a few months back from my own investigations; I found it didn't mention at least three of the bits.] If identifiers had their own struct without attempting to share everything with tree_common, this question would not even arise. It would also help towards solving the space-issue for identifiers, which currently take up far more memory than they really need, and pushes them into the next GC allocation bucket. Am I right in thinking that the only common thing that every "tree" really needs to have is the chain element and tree code? Neil.