From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12537 invoked by alias); 31 Oct 2002 21:10:34 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 12499 invoked from network); 31 Oct 2002 21:10:33 -0000 Received: from unknown (HELO egil.codesourcery.com) (66.92.14.122) by sources.redhat.com with SMTP; 31 Oct 2002 21:10:33 -0000 Received: from zack by egil.codesourcery.com with local (Exim 3.36 #1 (Debian)) id 187MaE-0003Zm-00; Thu, 31 Oct 2002 13:10:30 -0800 Date: Thu, 31 Oct 2002 13:10:00 -0000 From: Zack Weinberg To: Mark Mitchell Cc: Dale Johannesen , "gcc-patches@gcc.gnu.org" Subject: Re: Patch: stab info for const fields Message-ID: <20021031211030.GG5766@codesourcery.com> References: <20021031205056.GF5766@codesourcery.com> <5690000.1036097498@warlock.codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5690000.1036097498@warlock.codesourcery.com> User-Agent: Mutt/1.4i X-SW-Source: 2002-10/txt/msg01944.txt.bz2 On Thu, Oct 31, 2002 at 12:51:38PM -0800, Mark Mitchell wrote: > >In general I think we encode way too much information in DECLs which > >is redundant with their TYPEs. Off the top of my head: I don't see > >any legitimate reason why the size, size_unit, arguments, attributes, > >and possibly pointer_alias_set fields, and a bunch of the flags should > >ever differ from the corresponding field in TREE_TYPE (decl). > > I very much agree with this, in spirit. There may be things in some > languages that somehow make these things different, but I'm not sure what. > You carefully left out alignment; the GNU attribute extensions do allow > you to align variables differently from their types -- though I have > argued in the past that this is an abuse of the notion of type. I didn't intentionally leave it out; I missed it because it's buiried in a union. It is valuable to be able to say "_this_ _particular_ integer needs a specific alignment independent of what alignment the ABI gives the type" but I don't see any real reason why we couldn't create a special type structure for that. We already have to have a notion of "these two types are not the same but are still compatible" in the language- independent type algebra. > There are other attributes (like "unused") that do make sense for a > variable independently of its type, though. Yah. zw