repr(C) AIX Struct Alignment

[RalfJung]

@Jules-Bertholet

One potential approach, to address both this issue and the MSVC x86_32 uint64_t issue, is to split the notion of a type’s alignment into preferred and minimal alignment. These would be defined as follows:

I'd prefer an approach that confines the insanity to the two targets that decided they don't need common sense: have align_of return the alignment that all instances of a type respect (i.e., for double on AIX it is 4), but have struct computation sometimes add extra padding at the end. This also helps with other problems, for instance, we also need #[repr(C)] struct Zst([u8; 0]); to add padding to get a size of 1 on MSVC targets (see here).

We need to break with repr(C) == repr(linear) anyway; once we do, this should all be fixable.

@workingjubilee

The clang implementation still reports the _Alignof for the struct as 4. The struct may have to be given further padding, but that just brings us back to "repr(linear) is not repr(C)", not some alien universe.

I take it that clang does add the trailing padding as required by the docs?

I was about to say this _Alignof value sounds like a clang bug, but presumably if this struct type features as the 2nd field of another struct type, it will indeed be just 4-aligned, so 4 is indeed the actual minimal alignment of that type.

So really the oddity can be entirely described by adding more trailing padding? But... why would one do that?! Is it so that arrays of this type keep the double field 8-aligned if the array itself is 8-aligned, or so?