This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]