Re: Darwin gcc 3.3 sizeof of C++ structures with long long ints is strange

["Kevin B. Hendricks" <kevin dot hendricks at sympatico dot ca>]

Hi Andrew,

This is what Geoff sent to me originally and what I modified to get back to 
a layout more consistent with everyone else's.  The ZI sent test code has 
to pass for any platform porting OOo and does so for PPC Linux, S390 
Linux, x86 Linux, Irix, NetBSD, FreeBSD, Apple gcc 2.95, Apple gcc 3.1 
with -malign-natural, WIN, Solaris, etc.

Since gnu gcc 3.3 does not support -malign-natural, and does not follow the 
max4 convention that Apple's gcc 2.95 did, the only solution was to fix 
the "strange" (but as you point out technically correct) alignment just 
used for long long ints to be more consistent with max 4.  All of the 
other platforms do not treat alignment of doubles and long long ints 
differently in C++ structures.

The other solution would be to add -malign-natural support to gnu gcc 3.3. 
for Darwin.

I hope this explains things a bit better.

Kevin


---snip---
Re: some Darwin C++ stucture size issues
Date: 15/02/03 08:29 pm
From: Geoff Keating <geoffk at geoffk dot org>
To: kevin dot hendricks at sympatico dot ca

The problem you're seeing is most likely due to something in the
ADJUST_FIELD_ALIGN or maybe ROUND_TYPE_ALIGN macro in
config/rs6000/darwin.h in GCC.  To save you a checkout, the Apple
compiler has:

/* APPLE LOCAL begin Macintosh alignment 2002-2-26 ff */
/* This now supports the Macintosh power, mac68k, and natural
   alignment modes.  It now has one more parameter than the standard
   version of the ADJUST_FIELD_ALIGN macro.

   The macro works as follows: We use the computed alignment of the
   field if we are in the natural alignment mode or if the field is
   a vector.  Otherwise, if we are in the mac68k alignment mode, we
   use the minimum of the computed alignment and 16 (pegging at
   2-byte alignment).  If we are in the power mode, we peg at 32
   (word alignment) unless it is the first field of the struct, in
   which case we use the computed alignment.  */
#undef ADJUST_FIELD_ALIGN
#define ADJUST_FIELD_ALIGN(FIELD, COMPUTED, FIRST_FIELD_P)      \
  (TARGET_ALIGN_NATURAL ? (COMPUTED) :                          \
   (((COMPUTED) == RS6000_VECTOR_ALIGNMENT)                     \
    ? RS6000_VECTOR_ALIGNMENT                                   \
    : (MIN ((COMPUTED),                                         \
            (TARGET_ALIGN_MAC68K ? 16                           \
                                 : ((FIRST_FIELD_P) ? (COMPUTED) \
                                                    : 32))))))

I'm pretty sure that's not the same as FSF GCC, which has:

/* Darwin word-aligns FP doubles but doubleword-aligns 64-bit ints.  */
#define ADJUST_FIELD_ALIGN(FIELD, COMPUTED) \
  (TYPE_MODE (TREE_CODE (TREE_TYPE (FIELD)) == ARRAY_TYPE \
              ? get_inner_array_type (FIELD) \
              : TREE_TYPE (FIELD)) == DFmode \
   ? MIN ((COMPUTED), 32) : (COMPUTED))

In particular, I think the comment is wrong.

-- 
- Geoffrey Keating <geoffk at geoffk dot org>

On March 19, 2003 05:20 am, Andrew Haley wrote:
> Kevin B. Hendricks writes:
>  > 
>  > I am exploring the use of gcc 3.3 (based on CVS from yesterday) to 
build 
>  > OpenOffice.org under MacOSX/Darwin (we have had troubles with Apple's 
gcc 
>  > 3.1 that don't seem to happen under gcc 3.3)?
>  > 
>  > Unfortunately, the following structure alignment program shows the 
size of 
>  > structure C5 is 4 bytes larger than expected. 
>  > 
>  > If you look at the code the key issue is that C5 uses a long long int 
type.  
>  > If I replace the long long int with a double (both are 8 bytes in 
size) 
>  > the expected size is achieved.
>  > 
>  > Will someone familar with C++ structure alignment and Darwin please 
take a 
>  > look at this testcase for me?
>  > 
>  > Is there something funny happening with long long ints here?
> 
> You may be aware that the way C++ structs are laid out in memory has
> changed as a result of the multivendor C++ ABI.
> 
> It looks to me like sizeof(C5) is rounded up to a multiple of C5's
> alignment.  This is not very strange.  If you don't want this to
> happen, you can use __attribute__ ((packed)).
> 
> Andrew.
> 
> 
>