AIX repr(C) struct layout does not always match C compiler

[RalfJung]

The layout rules for the f64 type on AIX are very special, and we do not always correctly implement them. #149880 improved the situation, but to my knowledge some cases are still wrong. @workingjubilee please correct be if I am wrong.

Our current best understanding of the rather confusingly-written documentation for this is that

• f64 generally only has an alignment requirement of 4
• However, sometimes f64 fields will be 8-aligned (and possibly this also affects fields of struct types where the struct contains f64)

In particular, we currently compute the wrong layout for this type:

#[repr(C)]
struct Struct {  
  a1: f64,
  a2: u8,
}

The size should be 16, but it is 12.

Another one (with the comments indicating what the layout should be):

// Size: 24
#[repr(C)]
struct Floats {  
  a: f64, // at offset 0
  b: u8, // at offset 8
  c: f64, // at offset 12
}

Currently we compute the same offsets but we give the type a size of 20.

This can't be fully fixed on the Rust side without something like rust-lang/rfcs#3845 to resolve the conflict between the platform C layout and using the standard layout algorithm that repr(C) uses everywhere else.

[workingjubilee]

This seems to be an accurate description of the current situation and what we understand of it, yes.

Though we already layout struct Floats correctly for AIX's rules, now that the alignment is fixed. It's just your struct Struct example.

[workingjubilee]

Well, to clarify: we give the right offsets for struct Floats. We do not give the right total alignment of it, because it should be aligned to 8, which is otherwise a valid factor of 24.

The specific rule is, as I understand it, "if the struct contains f64 at offset 0, up the alignment of that field to 8". This does not apply to later instances of f64, but it can affect the padding in the total struct (because now sizes 12, 28, etc. are invalid, as they can factor 4 but not 8), which is why struct Struct should get the size of 16.

[workingjubilee]

I think there's some hidden gotchas in the actual, underspecified but material rules implemented by compilers, that require careful investigation to make sure that things are correctly aligned/padded in various compositional cases (the most interesting are the struct-in-struct cases).

[RalfJung]

Well, to clarify: we give the right offsets for struct Floats. We do not give the right total alignment of it, because it should be aligned to 8, which is otherwise a valid factor of 24.

In particular this means we give the wrong size to Floats.

The specific rule is, as I understand it, "if the struct contains f64 at offset 0, up the alignment of that field to 8". This does not apply to later instances of f64, but it can affect the padding in the total struct (because now sizes 12, 28, etc. are invalid, as they can factor 4 but not 8), which is why struct Struct should get the size of 16.

So... if Floats later appears as the 2nd field of another struct, it gets an 8-aligned offset?

We'll really need some way to just play around with different inputs for an actual C compiler and see what it does. Is there one on Godbolt that we can trust has the right behavior?

Also Cc @daltenty @gilamn5tr @amy-kwan as target maintainers.

[workingjubilee]

In particular this means we give the wrong size to Floats.

...gears turning

Oh yes, the size should not be 20.

So... if Floats later appears as the 2nd field of another struct, it gets an 8-aligned offset?

...I am truly not confident either way about that!

[workingjubilee]

@RalfJung based on https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.3?topic=cc-highly-configurable-compiler I believe that IBM intends to use clang as the basis of future versions of XLC, their C compiler suite for AIX. So while the IBM folks are obviously welcome to correct me if I am wrong, I think we should incline towards treating clang as gospel unless directed otherwise... or we find what seems like an "obvious" inconsistency, at which point we should be willing to jump much faster to "If there's nothing wrong with me, maybe there's something wrong with the universe?"