public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Zack Weinberg <zack@codesourcery.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: Dale Johannesen <dalej@apple.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: Patch: stab info for const fields
Date: Thu, 31 Oct 2002 13:10:00 -0000	[thread overview]
Message-ID: <20021031211030.GG5766@codesourcery.com> (raw)
In-Reply-To: <5690000.1036097498@warlock.codesourcery.com>

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

  reply	other threads:[~2002-10-31 21:10 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-30 15:16 Dale Johannesen
2002-10-30 22:01 ` Mark Mitchell
2002-10-31  9:42   ` Dale Johannesen
2002-10-31  9:47     ` Mark Mitchell
2002-10-31 10:25       ` Dale Johannesen
2002-10-31 11:06         ` Mark Mitchell
2002-10-31 12:50           ` Zack Weinberg
2002-10-31 12:54             ` Mark Mitchell
2002-10-31 13:10               ` Zack Weinberg [this message]
2002-10-31 13:12                 ` Mark Mitchell
2002-10-31 14:26             ` Joseph S. Myers
2002-10-31 11:21   ` Joseph S. Myers
2002-10-31 13:37 Richard Kenner
2002-10-31 13:52 ` Mark Mitchell
2002-10-31 14:05 Richard Kenner
2002-10-31 14:29 ` Mark Mitchell
2002-10-31 14:33 Richard Kenner
2002-10-31 15:14 ` Zack Weinberg
2002-10-31 15:24 Richard Kenner
2002-10-31 15:50 ` Zack Weinberg
2002-10-31 16:04 Richard Kenner
2002-10-31 16:26 ` Gabriel Dos Reis
2002-10-31 20:17   ` Zack Weinberg
2002-11-01  4:52     ` Gabriel Dos Reis
2002-11-01  3:45 Richard Kenner
2002-11-01  3:55 ` Andrew Haley
2002-11-01  4:45 Richard Kenner
2002-11-01  4:56 ` Andrew Haley
2002-11-01  4:59 Richard Kenner
2002-11-01 12:35 Richard Kenner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021031211030.GG5766@codesourcery.com \
    --to=zack@codesourcery.com \
    --cc=dalej@apple.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mark@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).