In triage, the issue appears to be that int64_t is 8-byte aligned on linux/arm, but the equivalent Go type (int64) is 4-byte aligned. We agree that cgo should probably be generating a memcpy to fix up the alignment, but that won't inherently fix the fact that the compiler issues a warning about the type. We also all agree there aren't easy answers here.

This generated C code is constructing a Go argument list that is going to be passed to a Go function. The Go argument list must exactly match what the Go function expects to find on the stack. For Go, for linux-arm, a uint64 value is aligned at a four-byte boundary, not an eight-byte boundary. So ``attribute((packed))` is required.

This does mean that the Data field is misaligned compared to what the C compiler expects. However, upon reflection, I don't agree with the compiler warning. I think it is clear that it is OK to write, in C,

typedef struct {
		int* p0;
		int64_t p1;
} __attribute__((__packed__)) _cgo_argtype;

Even if the alignment of int64_t is normally eight bytes, in this case the p1 field will be aligned at a four-byte boundary. The C compiler should handle that correctly. That's what __attribute__((packed)) means.

I don't see why that changes when p1 becomes a struct type that expects an eight-byte alignment.

So it seems to me that this is a bug in how zig handles __attribute__((packed)). Happy to hear other thoughts.

So, the warning comes from LLVM (not zig directly itself). I suspect the relevant issue is llvm/llvm-project#55520.

So using clang 14+ leads to the same warning https://c.godbolt.org/z/4cP5E9TaE.

As far as I can understand it's an early warning for:

typedef struct Data {
    int32_t a;
    int64_t b;
} Data;

typedef struct {
    int8_t x;
    Data p1;
} __attribute__((__packed__)) _cgo_argtype;

void useData(Data *v) {}

void use(_cgo_argtype *v) {
    useData(&v->p1); // <-- this is an unaligned pointer to Data, however `useData` doesn't necessarily know it's unaligned.
}

The linked issue (llvm/llvm-project#55520 (comment)) mentions:

As long as you don't take the address ("&" etc.) of the misaligned member, the compiler should reliably generate correct code.

So, the cgo generated code seems correct.

Even if the alignment of int64_t is normally eight bytes, in this case the p1 field will be aligned at a four-byte boundary. The C compiler should handle that correctly. That's what attribute((packed)) means.

Yeah, that's what's the confusing thing. I was also under the assumption that the expected alignment for arm is 4. If it's aligned less, like the C example above, then the warning makes more sense.

Maybe it's because, that the compiler doesn't know how aligned it should be -- e.g. maybe some NEON instruction expects higher alignment?

I guess the solution would be to silence that warning (-Wno-unaligned-access) in cgo code?

It should be possible for cmd/cgo to write out something like

#pragma GCC diagnostic ignored "-Wunaligned-access"

in the same place where it emits a pragma ignoring -Waddress-of-packed-member.

Change https://go.dev/cl/526915 mentions this issue: cmd/cgo: silence unaligned-access

Change https://go.dev/cl/528935 mentions this issue: cmd/cgo: silence unaligned-access