-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
volatile not respected when loading a packed struct #1761
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
Comments
You can't do volatile on a packed struct unless every load/store is a single atomic operation, because otherwise you might add data races, which is prohibited by C11 (which in general we should follow where applicable, except for lack of aliasing stuff so far). |
The piece of code you posted seems to be compiling to LLVM IR fine now: https://godbolt.org/z/rcb6zE1q6 Is there anything else that is needed to solve the issue? |
Packed structs behave differently and the original issue no longer applies to stage2. |
This is solved by the new packed struct semantics (#10113, #5049): define dso_local void @entry(ptr nonnull align 4 %0) #0 {
Entry:
%1 = alloca i32, align 4
%2 = load volatile i32, ptr %0, align 4
store i32 %2, ptr %1, align 4
%3 = load i32, ptr %1, align 4
%4 = and i32 %3, -129
%5 = or i32 128, %4
store i32 %5, ptr %1, align 4
%6 = load i32, ptr %1, align 4
store volatile i32 %6, ptr %0, align 4
ret void
} |
Is this really solved? If so we should update the docs. https://ziglang.org/documentation/master/#packed-struct
|
generates
The problem here is
call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 1 %3, i8* align 1 %2, i64 4, i1 false), !dbg !102
and specifically the last argi1 false
. That's a non-volatile load.This load should be volatile.
Arguably Zig should generate a ptrcast from the struct pointer to a pointer to u32 since that is <= register size, but if LLVM is doing the same thing when lowering memcpys - which it appears to be doing - then it's fine just to set the volatile bit.
We don't really have a way to test this other than pattern-matching the resulting LLVM IR, so I think we'll have to add some tests that do that. I already need something like that for #1682.
The text was updated successfully, but these errors were encountered: