stage3 fails the behavior tests #11450
Labels
Milestone
Comments
andrewrk
added
bug
|
I just got an failure in returns (127 is expected): I was going to open a new issue, but perhaps it is related to this one. Here is the failure: |
9 tasks
|
Status update: a debug build of stage3 is now passing the behavior tests for several targets and then failing on aarch64-macos: A release build of stage3 is segfaulting: Since these bugs are likely to already have test coverage somewhere in the main test suite, the best way to solve this issue I think is to press forward on the full test suite passing. Likely once that happens, this issue will have been solved somewhere along the way. |
Merged
export fn foo(x: u32) bool {
return switch (x) {
4...4 => false,
13 => true,
else => false,
};
}The problem is that it's not very helpful to debug this directly; the likely scenario is that a bug unrelated to switch is causing a miscompilation anywhere in the self-hosted compiler that deals with switch expressions. |
This was referenced Jul 13, 2022
Merged
|
Tests pass if you compile the IR with LLVM 13: 🤔 Using |
|
Possibly related: llvm/llvm-project#56585 |
|
I think you're correct about that zero-extension bug being related. I was looking into the compile issue Andrew was debugging on stream the other day. Here's the test case from the stream: comptime {
var x: ?i32 = null;
x = 2;
x.? *= 10;
}A debug build of stage3 accepts this code, but a release build rejects it. I traced the execution through Zig is performing the optional check with a This disassembly is from Here's the disassembly and contents of memory from a debug build (same source location, same commit): |
|
Oh boy. Yep, that matches my observations from that bug exactly. I observed it on a modified branch, but it sounds like you've just confirmed it on master. |
|
Sure enough, your hint leads right to it: ; (Optimized IR, LLVM 14)
define internal fastcc void @Sema.beginComptimePtrLoad(...) unnamed_addr #1 {
...
Else5: ; preds = %Then2
...
%94 = bitcast i1* %.sroa.gep923 to i8*
store i8 -1, i8* %94, align 8
...
; (Optimized IR, LLVM 13)
define internal fastcc void @Sema.beginComptimePtrLoad(...) unnamed_addr #1 {
...
Else5: ; preds = %Then2
...
%.sroa.2184.0.sroa_cast = bitcast i8* %.sroa.2184 to i1*
store i1 true, i1* %.sroa.2184.0.sroa_cast, align 8
... |
|
One way to work around the LLVM bug would be to do the null check by comparing against 0 instead of 1, right? That's the way I would expect a C compiler to do the check, anyway. (I'm new here, so apologies if I'm overlooking some history about why Zig does null checks this way). |
If we look at a simple optional check in terms of LLVM IR: var optional_foo: ?i32 = null;
fn doTheTest() !void {
if (optional_foo) |*foo| {
var x = foo.*;
_ = x;
}
}@test2.optional_foo = internal unnamed_addr global { i32, i1, [3 x i8] } { i32 undef, i1 false, [3 x i8] undef }, align 4
define internal fastcc i16 @test2.doTheTest() unnamed_addr #0 {
Entry:
%0 = alloca i32, align 4
%1 = load { i32, i1, [3 x i8] }, { i32, i1, [3 x i8] }* @test2.optional_foo, align 4
%2 = extractvalue { i32, i1, [3 x i8] } %1, 1
br i1 %2, label %Then, label %Else
Then: ; preds = %Entry
%3 = load i32, i32* getelementptr inbounds ({ i32, i1, [3 x i8] }, { i32, i1, [3 x i8] }* @test2.optional_foo, i32 0, i32 0), align 4
store i32 %3, i32* %0, align 4
br label %Block
Else: ; preds = %Entry
br label %Block
Block: ; preds = %Else, %Then
ret i16 0
}Zig is not doing a comparison against |
|
I see, thanks for explaining. Looks like LLVM is what is compiling that conditional branch on Just for comparison, I translated your example to C. clang compiles the Anyway, I don't have any opinions about what to do with the LLVM bug--just brought up the null check thing because the disassembly was somewhat unusual to me. |
That's not quite a one-to-one translation. Here is your C code translated to Zig: https://godbolt.org/z/hPn3bEjhW Thanks for making the observation! I definitely think you're onto something. |
andrewrk
added a commit
that referenced
this issue
Jul 19, 2022
This is a possible workaround for llvm/llvm-project#56585 On my computer it makes stage3-release go from false positive compilation errors on the behavior tests to "segmentation fault". Is this forwards progress or backwards progress? I have no idea. See #11450
|
Here's a data point: On my computer it makes stage3-release go from false positive compilation errors to "segmentation fault". Is this forwards progress or backwards progress? I have no idea. I will note however than before the LLVM 14 upgrade, I was getting "segmentation fault" when running stage3-release on the behavior tests. |
topolarity
added a commit
to topolarity/zig
that referenced
this issue
Jul 19, 2022
This is a workaround for llvm/llvm-project#56585 which causes writes to i1 in memory to be optimized to an incorrect value. Unfortunately, this does not save users from running into this bug with u1 in their own types. However, this does seem to be enough to get the behavior tests working. This resolves ziglang#11450 on my machine.
andrewrk
pushed a commit
that referenced
this issue
Jul 19, 2022
This is a workaround for llvm/llvm-project#56585 which causes writes to i1 in memory to be optimized to an incorrect value. Unfortunately, this does not save users from running into this bug with u1 in their own types. However, this does seem to be enough to get the behavior tests working. This resolves #11450 on my machine.
andrewrk
added a commit
that referenced
this issue
Jul 19, 2022
This is a possible workaround for llvm/llvm-project#56585 On my computer it makes stage3-release go from false positive compilation errors on the behavior tests to "segmentation fault". Is this forwards progress or backwards progress? I have no idea. See #11450
andrewrk
pushed a commit
that referenced
this issue
Jul 19, 2022
This is a workaround for llvm/llvm-project#56585 which causes writes to i1 in memory to be optimized to an incorrect value. Unfortunately, this does not save users from running into this bug with u1 in their own types. However, this does seem to be enough to get the behavior tests working. This resolves #11450 on my machine.
andrewrk
added a commit
that referenced
this issue
Jul 19, 2022
This is a possible workaround for llvm/llvm-project#56585 On my computer it makes stage3-release go from false positive compilation errors on the behavior tests to "segmentation fault". Is this forwards progress or backwards progress? I have no idea. See #11450
|
Stage3 behavior tests still fail on M1 Mac, using zig version 0.10.0-dev.3034. Stage1 and stage2 behavior tests pass without problems. |
|
|
Stage3 behavior tests still fail on M1, using zig version 0.10.0-dev.3041. Panics for the same test, stacktrace still shows unreachable code in stage2. |
|
wooster0
pushed a commit
to wooster0/zig
that referenced
this issue
Jul 24, 2022
This is a workaround for llvm/llvm-project#56585 which causes writes to i1 in memory to be optimized to an incorrect value. Unfortunately, this does not save users from running into this bug with u1 in their own types. However, this does seem to be enough to get the behavior tests working. This resolves ziglang#11450 on my machine.
wooster0
pushed a commit
to wooster0/zig
that referenced
this issue
Jul 24, 2022
This is a possible workaround for llvm/llvm-project#56585 On my computer it makes stage3-release go from false positive compilation errors on the behavior tests to "segmentation fault". Is this forwards progress or backwards progress? I have no idea. See ziglang#11450
wooster0
pushed a commit
to wooster0/zig
that referenced
this issue
Jul 24, 2022
This branch originally started out as a potential workaround to address ziglang#11450. It did not solve that problem, however, it did end up fixing ziglang#11498!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Zig Version:
0.10.0-dev.1855+a315d51c0After stage2 rebuilds itself, producing stage3, it no longer passes the behavior tests. In this snippet below you can see:
The text was updated successfully, but these errors were encountered: