panic: switch on corrupt value running code generated by self-hosted x86_64 backend

[ehaas]

Zig Version

0.14.0-dev.2050+4adf63aef

Steps to Reproduce and Observed Behavior

uname -a output: Linux system76-pc 6.9.3-76060903-generic #202405300957~1726766035~22.04~4092a0e~dev-Ubuntu SMP PREEMPT_DY x86_64 x86_64 x86_64 GNU/Linux

const std = @import("std");
pub fn main() !void {
    const query = try std.Target.Query.parse(.{ .arch_os_abi = "x86-netbsd.6.99" });
    _ = try std.zig.system.resolveTargetQuery(query);
}

Run with: zig run -fno-llvm test.zig

thread 8143 panic: switch on corrupt value
Unwind error at address `exe:0x103d8fb` (error.InvalidDebugInfo), trace may be incomplete

/home/ehaas/.local/zig-linux-x86_64-0.14.0-dev.2050+4adf63aef/lib/std/zig/system.zig:321:45: 0x10206bc in resolveTargetQuery (std.zig)
    if (query.os_version_max) |max| switch (max) {
                                            ^
/home/ehaas/test.zig:4:46: 0x101abb0 in main (test.zig)
    _ = try std.zig.system.resolveTargetQuery(query);
                                             ^
/home/ehaas/.local/zig-linux-x86_64-0.14.0-dev.2050+4adf63aef/lib/std/start.zig:618:37: 0x101b1a5 in posixCallMainAndExit (std.zig)
            const result = root.main() catch |err| {
                                    ^
/home/ehaas/.local/zig-linux-x86_64-0.14.0-dev.2050+4adf63aef/lib/std/start.zig:249:5: 0x1018016 in _start (std.zig)
    asm volatile (switch (native_arch) {
    ^

Expected Behavior

No output (this is what happens using the LLVM backend).

[ehaas]

Simplified repro that makes me think this might be a frontend issue and not backend:

const std = @import("std");

pub fn answer(query: u32) u32 {
    _ = query;
    return 42;
}

const S = struct {
    x: u32,
};


pub fn main() !void {
    var result: ?S = null;
    const query: ?u32 = null;

    top: {
        result = .{
            .x = answer(query orelse break :top),
        };
    }
    std.debug.print("{?}\n", .{result});
}

Running with the LLVM backend produces: test.S{ .x = 0 }
Running with self-hosted produces test.S{ .x = 2863311530 } (0xaa...)

It seems like the orelse break is producing a partially-constructed S instance; my expectation is that result should be null after running the code.

[Rexicon226]

Just adding a bit more information, I was curious what the behaviour on other backends was.

• riscv64 backend: null
• C backend: empty.S{ .x = 2863311530 }
• wasm backend: empty.S{ .x = 2863311530 }

this does make me a bit proud...

[mlugg]

This seems to me like expected behaviour and an RLS footgun, demonstrating another reason we IMO should adopt #12251 or similar. @Rexicon226, if anything, it seems to me like a bug that the RISC-V backend behaves this way; it should be encountering an instruction to set the alloc to non-null, then encountering a break instruction which effectively skips setting the payload.

[Rexicon226]

@Rexicon226, if anything, it seems to me like a bug that the RISC-V backend behaves this way; it should be encountering an instruction to set the alloc to non-null, then encountering a break instruction which effectively skips setting the payload.

Darn, I was hoping I had saved Zig.

Does this mean the value 0 here just comes out of thin air? Also, is there an issue tracking this?

[mlugg]

Yeah, the value will be undefined, it's whatever bytes happens to occupy the uninitialized field. I'll take a look for other issues later, and modify this issue as needed.

[jacobly0]

@mlugg could you update the labels when you get a chance so this is not blocking #22257, thanks 🙂