This is the mail archive of the gcc-bugs@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]

[Bug c++/32016] sizeof(class) always a multiple of 4 on 32 bit machine



------- Comment #4 from bliss1940-bbs at yahoo dot com  2007-05-21 23:22 -------
(In reply to comment #3)

I'm using arm-elf.  Thanks for the __attribute__((packed)).  That does indeed
remove the hole at the end.

I think we should agree to disagree.  You say it's an ABI issue but that seems
impossible.  All data members are chars and so can be at any address.

If you are thinking of accessing whole structures at once, to copy for
instance, then aligning on four byte addresses and accessing 4 bytes at a time
could be efficient.  But that's a compiler thing.  

Here's another way to look at it.  The hole at the end can't affect the
placement of the members in the struct.  But it can affect the placement of the
next struct in the array.  So if you wanted to copy the structs 4 bytes at a
time, putting them on 4 byte addresses would be a good idea.  But accessing the
data members can't be an alignment or ABI issue because the data members are
chars and are accessed one byte at a time.  

In my second example, I used shorts.  But here the alignment needs to be a
multiple of 2 bytes.  The only requirement for an address of a multiple of 4,
is for using 4 byte operands.  That's under the control of the compiler. 

Maybe we should just put this thing to bed. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32016


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