[cfe-dev] [llvm-dev] Struct padding

[David Chisnall via cfe-dev]

On 18 May 2017, at 09:50, mats petersson via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> The only difference is that it will zero initialize `d`, where the anonymous padding is `undef` (allows the compiler to optimise it away at times, I think).

This is one of the underspecified corner cases in the C spec (and the subject of some ongoing WG14 discussions).  In particular, for atomic structs to work, struct padding is required to be stable, so undef isn’t quite right (an optimiser is permitted to spot an atomic compare and exchange on a struct containing undef and allow assume undef != undef and so it will always fail).  Some architectures (for example, Alpha) make sub-word stores much more expensive and so field updates on these architectures may modify the following padding (which is the reason for the vagueness in the C spec and why sizeof(T) and sizeof(_Atomic(T)) are not required to be the same - on Alpha you’d likely want _Atomic(char) to be 64 bits).

It would be nice if LLVM had a way to differentiate between padding and non-padding struct fields (even if it were metadata, because losing the ‘padding’ attribute would impede optimisation but shouldn’t harm correctness).

David