-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stage2: array-like tuple initialization gets LLVM verification panic #11159
Comments
Based on inspecting the AIR, looks like the bug here is that either Sema needs to avoid generating a store to a comptime field, or that the LLVM backend needs to not generate a store when the target has no runtime bits. |
Note, as @topolarity pointed out, this doesn't actually work on stage1, but it has no error. In stage1, both However, an LLVM module verification panic is probably not the desired outcome in stage2 regardless of correct behavior. :) |
That's me :-) This does actually work on stage1, but the test case above just happens to overlap with #11162. Here's one that doesn't: test {
const T = @TypeOf(.{ @as(i32, -1234), @as(u32, 5678) });
var a: T = .{ -1234, 5678 };
_ = a;
} This works correctly on stage1 but panics on stage2, because of an AIR store to a comptime field: %16 = constant(i32, -1234)
...
%10 = alloc(*tuple{comptime i32 = -1234, comptime u32 = 5678})
%13 = struct_field_ptr_index_0(*i32, %10)
%17!= store(%13!, %16!) I think the bug is that Sema should not be generating that store of an |
This resolves ziglang#11159 The problem was that: 1. We were not correctly deleting the field stores after recognizing that an array initializer was a comptime-known value. 2. LLVM was not checking that the final type had no runtime bits, and so would generate an invalid store. This also adds several test cases for related bugs, just to check these in for later work.
This resolves ziglang#11159 The problem was that: 1. We were not correctly deleting the field stores after recognizing that an array initializer was a comptime-known value. 2. LLVM was not checking that the final type had no runtime bits, and so would generate an invalid store. This also adds several test cases for related bugs, just to check these in for later work.
This resolves ziglang#11159 The problem was that: 1. We were not correctly deleting the field stores after recognizing that an array initializer was a comptime-known value. 2. LLVM was not checking that the final type had no runtime bits, and so would generate an invalid store. This also adds several test cases for related bugs, just to check these in for later work.
This resolves ziglang#11159 The problem was that: 1. We were not correctly deleting the field stores after recognizing that an array initializer was a comptime-known value. 2. LLVM was not checking that the final type had no runtime bits, and so would generate an invalid store. This also adds several test cases for related bugs, just to check these in for later work.
result:
Works on stage1.
The text was updated successfully, but these errors were encountered: