packed union assignment issue

[lime flame]

i'm building an ARM emulator in Zig, i have a structure for the registers, it's a pretty elaborate packed struct for addressing the same data in different ways. The definition is pretty large, but ultimately i'm having issues with this failing ```c++
r.arm.hir.r08.usr = 8;
try std.testing.expectEqual(r.arm.hir.r08.usr, 8);

where `hir` looks like ```c++
packed struct {
    /// Program counter
    r15: u32,
    r14: Banked(u32),
    r13: Banked(u32),
    r12: FiqBanked(u32),
    r11: FiqBanked(u32),
    r10: FiqBanked(u32),
    r09: FiqBanked(u32),
    r08: FiqBanked(u32),
  },

and FiqBanked function is

pub fn FiqBanked(comptime T: type) type {
  return packed struct {
    usr: T,
    fiq: T
  };
}

Anyone see any major issues with this? i'm a little lost. Thanks in advance!

the error i get is expected 536871039, found 8 where that number doesn't seem to change

[odd granite]

usr and fiq do not share the same memory, because you defined FiqBanked as a packed structure rather than a union.

[lime flame]

that is correct, they shouldnt share the same memory in this case. the test reflects this, writing to fiq and reading the exact same location back to not have the same value

[wary pawn]

This definitely looks like a compiler bug

(Although, small note, your args to expectEqual should be the other way around for the error message to make more sense)

[lime flame]

thats what i thought as well, but the other way around gave me another error iirc. something about not being known at compile time

src/core/arm/registers.zig:253:44: error: unable to resolve comptime value
  try std.testing.expectEqual(15, r.arm.hir.r15);

which might be a hint to the issue i guess? maybe zig can't figure out what i want?

should i create an issue on GitHub? i think i can distil it down to just one file required to reproduce

[wary pawn]

Yeah, make an issue

[lime flame]

issue here https://github.com/ziglang/zig/issues/14922

[signal nacelle]

15 is of type comptime_int hence it’s trying to resolve it at comptime. You want @as(u32, 15). This doesn’t resolve the actual bug, but it explains this error you see here.

[lime flame]

oh, that makes sense actually. I totally knew that

[signal nacelle]

The actual bug is probably the lack of proper support for an integer type this large

[lime flame]

yeah i figured something like that might be the case, it's a wide guy. I haven't had time to mess with it more just yet, but i think i can change the values that wind up being wrong by shuffling the order of those fields around.

[wary pawn]

Ahh wait yeah okay that makes sense lol
Iirc LLVM sorta breaks for anything over 128 bits

[signal nacelle]

Wouldn’t an extern struct where each field has an alignment of 1 be what you want here?

[lime flame]

i think the issue with extern structs is i can't use things like u10. I can do a runtime cast tho i guess.

[signal nacelle]

Ah I see

Only saw those u32’s so assumed you only had those 🙂

[lime flame]

oh derp, i forgot i didn't post the entire source here. It's in that issue above if you care. In all reality, i don't have to build it this way, i just wanted too see how far i could push the compiler to do all the work for me lol