This is the mail archive of the
mailing list for the GCC project.
Re: PR 6212
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: mark at codesourcery dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 7 May 02 23:10:08 EDT
- Subject: Re: PR 6212
This is a language question as much as an implementation question. If
these things have different types, then you have to decide what all the
conversion rules are. On the other hand, saying that two things that
have the same type have different sizes is just plain wrong.
I must say that when we did the initial Ada implementation, we took that
approach: I wanted to be sure that the size (and alignment) of each object
was the same as its size.
That needed a tremendous amount of code and it has been the most tricky part
of the entire interface between the Ada front end and GCC. One of my
next projects was to eliminate that entire mess and take advantage of the
separate fields in a decl.
DECL_SIZE/DECL_ALIGN are just plain wrong, and should be eliminated.
Well, it's also DECL_SIZE_UNIT and DECL_MODE.
Using types gives you a way to provide feedback about possibly invalid
conversions, like converting a pointer to a byte-aligned int to a pointer
to a word-aligned int. The usual type theoretic rules would imply
you cannot go that way, but you can go the other way. This is the
whole point of a type system.
I don't follow. Objects still have types, but those types are more generic
than the object. In other words, if I have a record type that's 3 bytes long
and byte-aligned, I can make an object that's 4-byte-aligned (and hence 4
bytes long). If I make a pointer to that object, that's a pointer to a 3-byte
type, not a 4-byte type. I don't see how you can do things consistently
if you don't take that approach.
Moreover, what do you do about bitfields? Do we now have types with sizes that
are not multiples of bytes?