C backend emits incorrect type layouts for MSVC #31576

kcbanner commented 2026年03月19日 07:42:05 +01:00

Zig Version

3edaef9e01

Steps to Reproduce and Observed Behavior

#31403 introduced some new assertions (via zig_static_assert) emitted by the CBE to verify that the C compiler agrees with the size / alignment of generated structs.

There was some discussion about this already on zulip, which I'll duplicate here.

When building from source, these assertions are tripped, ie:

C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.c(12881,1): error C2466: cannot allocate an array of constant size 0 [C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.vcxproj]
C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.c(12887,1): error C2466: cannot allocate an array of constant size 0 [C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.vcxproj]
C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.c(12900,1): error C2466: cannot allocate an array of constant size 0 [C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.vcxproj]
C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.c(19580,1): error C2466: cannot allocate an array of constant size 0 [C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.vcxproj]
...

One specific example:

zig_static_assert(sizeof (struct Zcu_LazySrcLoc_Offset_51837) == 16, "incorrect size");

I inspected the actual values by smuggling them into error messages like this:

#define PRINT_STRUCT_INFO(t) void print_info_##t(char (*size)[sizeof(struct t)], char (*align)[_Alignof(struct t)]) { __pragma(message(__FUNCSIG__)); }
PRINT_STRUCT_INFO(Zcu_LazySrcLoc_Offset_51837);

Which results in:

void __cdecl print_info_Zcu_LazySrcLoc_Offset_51837(char (*)[24],char (*)[8])

So, cl.exe is choosing to do something unexpected with the zig_packed, here is a reduction:

typedef struct {
 uint32_t a;
 uint32_t b;
 uint32_t c;
} S;
#pragma pack(1)
typedef union {
 S s;
} U;
#pragma pack()

typedef struct {
 zig_align(8) U u;
 uint8_t flag;
} Foo;
typedef struct {
 zig_align(8) zig_packed(union { S s; }) U;
 uint8_t flag;
} FooInline;

In this case, FooInline is 24 bytes and Foo is 16 bytes, under cl.exe. They are both 16 bytes via clang.

Jacob pointed out that if we swap the ordering of zig_packed and zig_align, ie. zig_packed(union { S s; }) zig_align(8), this resolves the immediate issue, ie. the sizes match.

Based on this, I came up with this diff:

diff --git a/lib/zig.h b/lib/zig.h
index dc5666d894..e3594252c8 100644
--- a/lib/zig.h
+++ b/lib/zig.h
@@ -274,6 +274,12 @@
 #define zig_packed(definition) zig_packed_unavailable
 #endif
+#if defined(zig_msvc)
+#define zig_packed_align(align, definition) zig_packed(definition) zig_align(align)
+#else
+#define zig_packed_align(align, definition) zig_align(align) zig_packed(definition)
+#endif
+
 #if zig_has_attribute(section) || defined(zig_tinyc)
 #define zig_linksection(name) __attribute__((section(name)))
 #define zig_linksection_fn zig_linksection
diff --git a/src/codegen/c/type/render_defs.zig b/src/codegen/c/type/render_defs.zig
index 52bf573064..3ab0f2f5a0 100644
--- a/src/codegen/c/type/render_defs.zig
+++ b/src/codegen/c/type/render_defs.zig
@@ -559,11 +559,14 @@ fn defineUnionAuto(
 });
 if (payload_has_bits) {
 try w.writeByte(' ');
- if (overalign) {
+ if (pack and overalign) {
+ try w.print("zig_packed_align({d}, ", .{union_type.alignment.toByteUnits().?});
+ } else if (overalign) {
 // Specify the alignment of `union { ... } payload;` to align the union's `struct`.
 try w.print("zig_align({d}) ", .{union_type.alignment.toByteUnits().?});
+ } else if (pack) {
+ try w.writeAll("zig_packed(");
 }
- if (pack) try w.writeAll("zig_packed(");
 try w.writeAll("union {\n");
 for (0..enum_tag_ty.enumFieldCount(zcu)) |field_index| {
 const field_ty = ty.fieldType(field_index, zcu);
diff --git a/stage1/zig.h b/stage1/zig.h
index 0b9c6e58ca..0891618013 100644
--- a/stage1/zig.h
+++ b/stage1/zig.h
@@ -274,6 +274,12 @@
 #define zig_packed(definition) zig_packed_unavailable
 #endif
+#if defined(zig_msvc)
+#define zig_packed_align(align, definition) zig_packed(definition) zig_align(align)
+#else
+#define zig_packed_align(align, definition) zig_align(align) zig_packed(definition)
+#endif
+
 #if zig_has_attribute(section) || defined(zig_tinyc)
 #define zig_linksection(name) __attribute__((section(name)))
 #define zig_linksection_fn zig_linksection

However, as Jacob also pointed out, there are further issues:

struct Foo { int x; };
struct Bar { __declspec(align(4)) int y; };
#pragma pack(1)
struct WithFoo { __declspec(align(1)) struct Foo foo; char after; };
struct WithBar { __declspec(align(1)) struct Bar bar; char after; };
int sizeof_with_foo = sizeof(struct WithFoo);
int sizeof_with_bar = sizeof(struct WithBar);

Here, sizeof_with_foo is 5 and sizeof_with_bar is 8, under cl.exe.

This problem affects the Zcu_LazySrcLoc_Offset_51837 case, zig_packed union has a struct field that itself uses zig_align(8):

struct Zcu_LazySrcLoc_Offset_TracedOffset_51840 { /* Zcu.LazySrcLoc.Offset.TracedOffset */
 zig_align(8) enum__zig_Ast_Node_Offset_11866 x;
};

I'm not sure how to solve this in the general case, as there doesn't seem to be a way to force cl.exe to pack these unions / structs the way we want it to.

Perhaps we could have the CBE notice it is emitting this pattern (an aligned struct field inside a type we are going to later wrap with zig_packed), and emit instead (using the above as an example) a version of Zcu_LazySrcLoc_Offset_TracedOffset_51840 that doesn't specify zig_align on it's first field. If the affected struct was going to be used in both a non-packed parent struct / union and a packed one, we would have to emit two versions (one without the align attribute and one with) and select the correct one based on the context.

My focus for this issue was specifically the ability to build the zig compiler itself from source on Windows, as this is the workflow I use to follow master branch.

Expected Behavior

CBE output should be compatible with MSVC.

### Zig Version 3edaef9e011ac500f66c9ee0ba3ea24be905bcde ### Steps to Reproduce and Observed Behavior https://codeberg.org/ziglang/zig/pulls/31403 introduced some new assertions (via `zig_static_assert`) emitted by the CBE to verify that the C compiler agrees with the size / alignment of generated structs. There was some discussion about this already on [zulip](https://zsf.zulipchat.com/#narrow/channel/454360-compiler/topic/type.20resolution/near/578767693), which I'll duplicate here. When building from source, these assertions are tripped, ie: ``` C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.c(12881,1): error C2466: cannot allocate an array of constant size 0 [C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.vcxproj] C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.c(12887,1): error C2466: cannot allocate an array of constant size 0 [C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.vcxproj] C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.c(12900,1): error C2466: cannot allocate an array of constant size 0 [C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.vcxproj] C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.c(19580,1): error C2466: cannot allocate an array of constant size 0 [C:\cygwin64\home\kcbanner\kit\zig\build-release\zig2.vcxproj] ... ``` One specific example: ``` zig_static_assert(sizeof (struct Zcu_LazySrcLoc_Offset_51837) == 16, "incorrect size"); ``` I inspected the actual values by smuggling them into error messages like this: ``` #define PRINT_STRUCT_INFO(t) void print_info_##t(char (*size)[sizeof(struct t)], char (*align)[_Alignof(struct t)]) { __pragma(message(__FUNCSIG__)); } PRINT_STRUCT_INFO(Zcu_LazySrcLoc_Offset_51837); ``` Which results in: ``` void __cdecl print_info_Zcu_LazySrcLoc_Offset_51837(char (*)[24],char (*)[8]) ``` So, cl.exe is choosing to do something unexpected with the `zig_packed`, here is a reduction: ```c typedef struct { uint32_t a; uint32_t b; uint32_t c; } S; #pragma pack(1) typedef union { S s; } U; #pragma pack() typedef struct { zig_align(8) U u; uint8_t flag; } Foo; typedef struct { zig_align(8) zig_packed(union { S s; }) U; uint8_t flag; } FooInline; ``` In this case, `FooInline` is 24 bytes and `Foo` is 16 bytes, under cl.exe. They are both 16 bytes via clang. Jacob pointed out that if we swap the ordering of `zig_packed` and `zig_align`, ie. `zig_packed(union { S s; }) zig_align(8)`, this resolves the immediate issue, ie. the sizes match. Based on this, I came up with this diff: ```diff diff --git a/lib/zig.h b/lib/zig.h index dc5666d894..e3594252c8 100644 --- a/lib/zig.h +++ b/lib/zig.h @@ -274,6 +274,12 @@ #define zig_packed(definition) zig_packed_unavailable #endif +#if defined(zig_msvc) +#define zig_packed_align(align, definition) zig_packed(definition) zig_align(align) +#else +#define zig_packed_align(align, definition) zig_align(align) zig_packed(definition) +#endif + #if zig_has_attribute(section) || defined(zig_tinyc) #define zig_linksection(name) __attribute__((section(name))) #define zig_linksection_fn zig_linksection diff --git a/src/codegen/c/type/render_defs.zig b/src/codegen/c/type/render_defs.zig index 52bf573064..3ab0f2f5a0 100644 --- a/src/codegen/c/type/render_defs.zig +++ b/src/codegen/c/type/render_defs.zig @@ -559,11 +559,14 @@ fn defineUnionAuto( }); if (payload_has_bits) { try w.writeByte(' '); - if (overalign) { + if (pack and overalign) { + try w.print("zig_packed_align({d}, ", .{union_type.alignment.toByteUnits().?}); + } else if (overalign) { // Specify the alignment of `union { ... } payload;` to align the union's `struct`. try w.print("zig_align({d}) ", .{union_type.alignment.toByteUnits().?}); + } else if (pack) { + try w.writeAll("zig_packed("); } - if (pack) try w.writeAll("zig_packed("); try w.writeAll("union {\n"); for (0..enum_tag_ty.enumFieldCount(zcu)) |field_index| { const field_ty = ty.fieldType(field_index, zcu); diff --git a/stage1/zig.h b/stage1/zig.h index 0b9c6e58ca..0891618013 100644 --- a/stage1/zig.h +++ b/stage1/zig.h @@ -274,6 +274,12 @@ #define zig_packed(definition) zig_packed_unavailable #endif +#if defined(zig_msvc) +#define zig_packed_align(align, definition) zig_packed(definition) zig_align(align) +#else +#define zig_packed_align(align, definition) zig_align(align) zig_packed(definition) +#endif + #if zig_has_attribute(section) || defined(zig_tinyc) #define zig_linksection(name) __attribute__((section(name))) #define zig_linksection_fn zig_linksection ``` However, as Jacob also pointed out, there are further issues: ``` struct Foo { int x; }; struct Bar { __declspec(align(4)) int y; }; #pragma pack(1) struct WithFoo { __declspec(align(1)) struct Foo foo; char after; }; struct WithBar { __declspec(align(1)) struct Bar bar; char after; }; int sizeof_with_foo = sizeof(struct WithFoo); int sizeof_with_bar = sizeof(struct WithBar); ``` Here, `sizeof_with_foo` is 5 and `sizeof_with_bar` is 8, under cl.exe. This problem affects the `Zcu_LazySrcLoc_Offset_51837` case, `zig_packed` union has a struct field that itself uses `zig_align(8)`: ```c struct Zcu_LazySrcLoc_Offset_TracedOffset_51840 { /* Zcu.LazySrcLoc.Offset.TracedOffset */ zig_align(8) enum__zig_Ast_Node_Offset_11866 x; }; ``` I'm not sure how to solve this in the general case, as there doesn't seem to be a way to force cl.exe to pack these unions / structs the way we want it to. Perhaps we could have the CBE notice it is emitting this pattern (an aligned struct field inside a type we are going to later wrap with `zig_packed`), and emit instead (using the above as an example) a version of `Zcu_LazySrcLoc_Offset_TracedOffset_51840` that doesn't specify `zig_align` on it's first field. If the affected struct was going to be used in both a non-packed parent struct / union and a packed one, we would have to emit two versions (one without the align attribute and one with) and select the correct one based on the context. My focus for this issue was specifically the ability to build the zig compiler itself from source on Windows, as this is the workflow I use to follow master branch. ### Expected Behavior CBE output should be compatible with MSVC.

mlugg commented 2026年03月19日 10:55:54 +01:00

It's worth noting for clarity that AFAIK the only reason this regressed is because of the assertions: we were probably emitting incorrect layouts on MSVC before that PR was merged, but it just happened to not break anything. In other words, we've converted a miscompilation into a compile error, which is an improvement :P

This issue is obviously valid and should remain open, but I just want to note that regarding the use case:

My focus for this issue was specifically the ability to build the zig compiler itself from source on Windows, as this is the workflow I use to follow master branch.

To be clear, it should be possible to bootstrap Zig on Windows using Clang, right? I've not tried it myself, but AIUI, that should already cause all of the GNU-style "attribute" paths in zig.h to be used, sidestepping this issue. Obviously the resulting bootstrap chain from MSVC is longer (you first need to build Clang with MSVC!), but it should at least work.

It's worth noting for clarity that AFAIK the only reason this regressed is because of the assertions: we were probably emitting incorrect layouts on MSVC *before* that PR was merged, but it just happened to not break anything. In other words, we've converted a miscompilation into a compile error, which *is* an improvement :P This issue is obviously valid and should remain open, but I just want to note that regarding the use case: > My focus for this issue was specifically the ability to build the zig compiler itself from source on Windows, as this is the workflow I use to follow master branch. To be clear, it should be possible to bootstrap Zig on Windows using Clang, right? I've not tried it myself, but AIUI, that should already cause all of the GNU-style "attribute" paths in `zig.h` to be used, sidestepping this issue. Obviously the resulting bootstrap chain from MSVC is longer (you first need to build Clang with MSVC!), but it should at least work.

kcbanner commented 2026年03月20日 02:45:05 +01:00

To be clear, it should be possible to bootstrap Zig on Windows using Clang, right? I've not tried it myself, but AIUI, that should already cause all of the GNU-style "attribute" paths in zig.h to be used, sidestepping this issue. Obviously the resulting bootstrap chain from MSVC is longer (you first need to build Clang with MSVC!), but it should at least work.

Yes, using the devkit (ie. zig cc / c++) works to compile from source.

I did attempt compiling using clang 19 (the one you can install via the MSVC installer), and I wasn't able to bootstrap with that. First, it required this change to CMakeLists.txt:

- target_link_libraries(zig1 LINK_PUBLIC m)
+ if (not WIN32)
+ target_link_libraries(zig1 LINK_PUBLIC m)
+ endif()

With zig1.exe building, it crashed in the next phase with a stack overflow. I think the difference here in the clangs is the one called via zig cc defaults to the gnu abi, instead of msvc. Perhaps this is somehow the cause of the stack overflow.

> To be clear, it should be possible to bootstrap Zig on Windows using Clang, right? I've not tried it myself, but AIUI, that should already cause all of the GNU-style "attribute" paths in zig.h to be used, sidestepping this issue. Obviously the resulting bootstrap chain from MSVC is longer (you first need to build Clang with MSVC!), but it should at least work. Yes, using the devkit (ie. zig cc / c++) works to compile from source. I did attempt compiling using clang 19 (the one you can install via the MSVC installer), and I wasn't able to bootstrap with that. First, it required this change to CMakeLists.txt: ```diff - target_link_libraries(zig1 LINK_PUBLIC m) + if (not WIN32) + target_link_libraries(zig1 LINK_PUBLIC m) + endif() ``` With zig1.exe building, it crashed in the next phase with a stack overflow. I think the difference here in the clangs is the one called via zig cc defaults to the gnu abi, instead of msvc. Perhaps this is somehow the cause of the stack overflow.

andrewrk commented 2026年03月26日 01:32:26 +01:00

Another thing to consider is having msvc be treated effectively as a different "object format". So we would have -ofmt=c (doesn't attempt msvc compatibility) and -ofmt=msvc (only aims for msvc compatibility).

Maybe that would simplify the implementation, or at least simplify the generated code that doesn't have to target MSVC.

Another thing to consider is having msvc be treated effectively as a different "object format". So we would have `-ofmt=c` (doesn't attempt msvc compatibility) and `-ofmt=msvc` (only aims for msvc compatibility). Maybe that would simplify the implementation, or at least simplify the generated code that doesn't have to target MSVC.

kcbanner commented 2026年03月26日 01:40:55 +01:00

That's an interesting thought, with a relaxed set of requirements it might be a lot easier to handle some of these esoteric compiler bugs / implementation details.

The usefulness of being able to target msvc from my view is purely for bootstrapping - it's just nice to be able to start with zig-bootstrap and the system compiler and get a fully functional zig install (including all the llvm parts, as long as those are required).

So that being said, I'm not sure if what these asserts are asserting actually impacts the runtime correctness of the specific output in this case (ie. the compiler), and I haven't looked too far into that yet. If the answer is that it doesn't actually impact things, then perhaps this msvc subset could start by simply just disabling these assertions. Since up until these asserts were added, things were working for some definition of working - I never ran into issues bootstrapping - but it's very possible I was just lucky.

That's an interesting thought, with a relaxed set of requirements it might be a lot easier to handle some of these esoteric compiler bugs / implementation details. The usefulness of being able to target msvc from my view is purely for bootstrapping - it's just nice to be able to start with zig-bootstrap and the system compiler and get a fully functional zig install (including all the llvm parts, as long as those are required). So that being said, I'm not sure if what these asserts are asserting actually impacts the runtime correctness of the specific output in this case (ie. the compiler), and I haven't looked too far into that yet. If the answer is that it doesn't actually impact things, then perhaps this `msvc` subset could start by simply just disabling these assertions. Since up until these asserts were added, things were working for some definition of working - I never ran into issues bootstrapping - but it's very possible I was just lucky.

andrewrk commented 2026年03月26日 01:50:15 +01:00

We don't have to go that far just to delete the assertions. Those can be behind a -Ddebug-cbe flag when building the compiler, off by default.

We don't have to go that far just to delete the assertions. Those can be behind a `-Ddebug-cbe` flag when building the compiler, off by default.

mlugg commented 2026年03月26日 10:59:28 +01:00

I am strongly against deleting the assertions, in any case. Them failing means that the C backend is emitting types which are not laid out how it thinks they are, and that means many usages of those types will miscompile (simple stack or global variables might work okay, but even that could break in some cases). Perhaps in practice we can still bootstrap to a functional zig (and pray that it's not got some subtle miscompilation), but even if that's true today, it could break at any time. Deleting the assertions is quite literally just turning a compiler bug from an error message into a miscompilation which I do not think is a productive step to take.

A separate mode for MSVC could be useful. That way we could emit the lowering proposed by Jacob, where we force every type to be align(1) at its definition site and overalign back to the right alignment in a typedef. It's desirable to not do that in the "normal" C backend output because we would end up heavily relying on compiler extensions for what could be standard C; but an MSVC-specific mode where we're free to rely on the extensions at all times mitigates that concern.

I am strongly against deleting the assertions, in any case. Them failing means that the C backend is emitting types which are not laid out how it thinks they are, and that means many usages of those types will miscompile (simple stack or global variables *might* work okay, but even that *could* break in some cases). Perhaps in practice we can still bootstrap to a functional zig (and pray that it's not got some subtle miscompilation), but even if that's true today, it could break at any time. Deleting the assertions is quite literally just turning a compiler bug from an error message into a miscompilation which I do not think is a productive step to take. A separate mode for MSVC could be useful. That way we could emit the lowering proposed by Jacob, where we force every type to be align(1) at its definition site and overalign back to the right alignment in a typedef. It's desirable to *not* do that in the "normal" C backend output because we would end up heavily relying on compiler extensions for what could be standard C; but an MSVC-specific mode where we're free to rely on the extensions at all times mitigates that concern.