andrewrk
commented
1 year ago As a workaround, you might try disabling LTO.
Open IntegratedQuantum opened 1 year ago
andrewrk
commented
1 year ago As a workaround, you might try disabling LTO.
IntegratedQuantum
commented
1 year ago It compiles. However it doesn't run correctly. It's outputting wrong data to the network which in result leads to a crash.
I managed to find the relevant code. It appears to be the same piece of code as in #13348, so it's likely the same issue:
pub fn sendRequest(conn: *Connection, requests: []chunk.ChunkPosition) !void {
if(requests.len == 0) return;
var data = try main.threadAllocator.alloc(u8, 16*requests.len);
defer main.threadAllocator.free(data);
var remaining = data;
for(requests) |req| {
std.mem.writeIntBig(chunk.ChunkCoordinate, remaining[0..4], req.wx);
std.mem.writeIntBig(chunk.ChunkCoordinate, remaining[4..8], req.wy);
std.mem.writeIntBig(chunk.ChunkCoordinate, remaining[8..12], req.wz);
std.mem.writeIntBig(chunk.ChunkCoordinate, remaining[12..16], req.voxelSize); // ← this line
remaining = remaining[16..];
}
try conn.sendImportant(id, data);
}req.voxelSize is a u31 and it only ever has the values {1, 2, 4, 8, 16, 32}
chunk.ChunkCoordinate is i32
Here a sample of the data it actually produced:
wx, wy, wz are equivalent to a debug build all of these should be 0, 0, 0, 1
/\ /\
/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\ /¯¯¯¯¯¯¯¯¯\
255, 255, 255, 96, 255, 255, 255, 224, 255, 255, 255, 224, 0, 0, 0, 1,
255, 255, 255, 96, 255, 255, 255, 224, 0, 0, 0, 0, 0, 0, 0, 2,
255, 255, 255, 96, 0, 0, 0, 0, 255, 255, 255, 224, 0, 0, 0, 4,
255, 255, 255, 96, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8,
255, 255, 255, 128, 255, 255, 255, 160, 255, 255, 255, 192, 0, 0, 0, 16,
255, 255, 255, 128, 255, 255, 255, 160, 255, 255, 255, 224, 0, 0, 0, 32,
255, 255, 255, 128, 255, 255, 255, 160, 0, 0, 0, 0, 0, 0, 0, 64,
255, 255, 255, 128, 255, 255, 255, 160, 0, 0, 0, 32, 0, 0, 0, 128,
255, 255, 255, 128, 255, 255, 255, 224, 255, 255, 255, 224, 0, 0, 0, 1This pattern continues, cycling through {1, 2, 4, 8, 16, 32, 64, 128}
If I try to print the req.voxelSize directly, it starts working. So I'm guessing this is some issue in the optimizer.
IntegratedQuantum
commented
1 year ago I just updated to 0.11.0-dev.368+1829b6eab and the error seems to be resolved.
Vexu
commented
1 year ago I'm able to reproduce this (or something similar) with https://github.com/Vexu/bun/commit/94d54c3fd1743b8851aa1873aabacf0ce8064ff0 and running make headers.
Vexu
commented
1 year ago Reduction:
fn FnPtrStage2Wrap(comptime T: anytype) @TypeOf(&struct {
const FnPtrType = T;
pub const fn_ptr: FnPtrType = undefined;
}.fn_ptr) {
return &struct {
const FnPtrType = T;
pub const fn_ptr: FnPtrType = undefined;
}.fn_ptr;
}
fn foo() u32 {
return 0;
}
test {
const a: @TypeOf(FnPtrStage2Wrap(@TypeOf(foo))) = foo;
_ = a();
}
Zig Version
0.10.0-dev.4640+20925b2f5
Steps to Reproduce and Observed Behavior
I tried to reduce this error, but I was unable to do that. Whenever I remove too many lines of code the error transforms into #13348. I think the error requires a certain function(+inlined calls) size. Maybe llvm tries to make the function external if it gets too big?
Anyways because I wasn't able to reduce it, here is a link to the exact commit that I tested it with: https://github.com/PixelGuys/Cubyz/commit/d4e9fa2c441bdb146388770d04fde6be74ff350f
This is the output that I get:
Expected Behavior
It should compile without an error like in release-small and release-safe and debug.