Hi,
> Unfortunately another PCS bug has come to light with the layout of
> structs whose alignment is dominated by a 64-bit bitfield element. Such
> fields in the type list appear to have alignment 1, but in reality, for
> the purposes of alignment of the underlying structure, the alignment is
> derived from the underlying bitfield's type. We've been getting this
> wrong since support for over-aligned record types was added several
> releases back. Worse still, the existing code may generate unaligned
> memory accesses that may fault on some versions of the architecture.
>
> I'd appreciate a comment from someone with a bit more knowledge of
> record layout - the code in stor-layout.c looks hideously complex when
> it comes to bit-field layout; but it's quite possible that all of that
> is irrelevant on Arm.
I am not really an expert here, Joseph might know the right answers.
I think there are two different alignment values, one is the minimum
alignment for a type within another structure, that can be computed
with:
min_align_of_type (type)
and there is a possibly greater value that tells how a type is aligned
when used alone:
TYPE_ALIGN_UNIT (type)
I thought both are always identical on arm, but maybe they are not.
They are for instance different for double on x86_64 in structures that
type is 4-byte aligned, and used alone, it is 8-byte aligned.
I wonder why you have to iterate over all the type members.
for instance this also gets the right alignment of the bit field type:
--- arm/arm.c (Revision 267164)
+++ arm/arm.c (Arbeitskopie)
@@ -6622,6 +6622,8 @@
ret = -1;
}
+ if (min_align_of_type (const_cast<tree>(type)) > PARM_BOUNDARY /
BITS_PER_UNIT)
+ return 1;
return ret;
}
But I might have missed the point why this needs to be dome this way.
Regards
Bernd.
