On Tue, Oct 16, 2007 at 12:53:13AM +0200, Andi Kleen wrote:
> > Actually no. In 32-bit mode, double is aligned on a 4 byte boundary, not
> > an 8
> > byte boundary, unless you use -malign-double, which breaks the ABI. This
> > has
> > been a 'feature' of the original AT&T 386 System V ABI that Linux uses for
> > 32-bit x86 processors. With the SCO mess, it may be hard to ever change
> > that
> > ABI....
>
> My gcc doesn't agree with you (I actually checked before posting)
>
> ~> cat t.c
>
> int main(void)
> {
> double x;
> printf("%d\n", __alignof__(x));
> return 0;
> }
> ~> gcc -m32 -o t t.c
> t.c: In function ‘main’:
> t.c:5: warning: incompatible implicit declaration of built-in function
> ‘printf’
> ~> ./t
> 8
> ~>
>
Doubles that are scalar variables are aligned on a 64-bit boundary, but doubles
that are within structures are only aligned to a 32-bit boundary, which comes
from the published i386 ABI from System V. Here is the code in question from
gcc/config/i386/i386.h:
/* The published ABIs say that doubles should be aligned on word
boundaries, so lower the alignment for structure fields unless
-malign-double is set. */
/* ??? Blah -- this macro is used directly by libobjc. Since it
supports no vector modes, cut out the complexity and fall back
on BIGGEST_FIELD_ALIGNMENT. */
#ifdef IN_TARGET_LIBS
#ifdef __x86_64__
#define BIGGEST_FIELD_ALIGNMENT 128
#else
#define BIGGEST_FIELD_ALIGNMENT 32
#endif
#else
#define ADJUST_FIELD_ALIGN(FIELD, COMPUTED) \
x86_field_alignment (FIELD, COMPUTED)
#endif
And this is where we recompute the alignment in i386.c:
int
x86_field_alignment (tree field, int computed)
{
enum machine_mode mode;
tree type = TREE_TYPE (field);
if (TARGET_64BIT || TARGET_ALIGN_DOUBLE)
return computed;
mode = TYPE_MODE (TREE_CODE (type) == ARRAY_TYPE
? get_inner_array_type (type) : type);
if (mode == DFmode || mode == DCmode
|| GET_MODE_CLASS (mode) == MODE_INT
|| GET_MODE_CLASS (mode) == MODE_COMPLEX_INT)
return MIN (32, computed);
return computed;
}
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
