[llvm-bugs] [Bug 46386] New: Miscompile with inalloca/exception/inlining
via llvm-bugs
llvm-bugs at lists.llvm.org
Thu Jun 18 11:15:31 PDT 2020
https://bugs.llvm.org/show_bug.cgi?id=46386
Bug ID: 46386
Summary: Miscompile with inalloca/exception/inlining
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: aeubanks at google.com
CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org
Brought up in https://reviews.llvm.org/D80951.
```
#include <cstdio>
struct A {
__attribute((optnone)) A(int) noexcept { z[1] = 10; }
__attribute((optnone)) A() {
z[1] = 5;
throw 1;
}
__attribute((optnone)) ~A() { printf("%d %p\n", z[1], this); }
int z[10000];
};
__attribute((optnone)) void foo(int z, A a) noexcept {}
__attribute((always_inline)) static int inner() {
try {
foo(1, A());
} catch (...) {
}
return 3;
}
void bar() {
for (int i = 0; i < 10; ++i) {
foo(inner(), A(1));
}
}
int main() { bar(); }
```
seems to be miscompiled on Win32. It should print "10 XXXXXXXX" where XXXXXXXX
is constant (no stack leak).
But instead of "10" it prints a random (but consistent within a run) value.
LLVM IR:
```
; Function Attrs: noinline optnone
define dso_local void @"?bar@@YAXXZ"() #1 personality i8* bitcast (i32 (...)*
@__CxxFrameHandler3 to i8*) {
entry:
%i = alloca i32, align 4
store i32 0, i32* %i, align 4
br label %for.cond
for.cond: ; preds = %for.inc, %entry
%0 = load i32, i32* %i, align 4
%cmp = icmp slt i32 %0, 10
br i1 %cmp, label %for.body, label %for.end
for.body: ; preds = %for.cond
%inalloca.save = call i8* @llvm.stacksave()
%argmem = alloca inalloca <{ i32, %struct.A }>, align 4
%1 = getelementptr inbounds <{ i32, %struct.A }>, <{ i32, %struct.A }>*
%argmem, i32 0, i32 1
%call = call x86_thiscallcc %struct.A* @"??0A@@QAE at H@Z"(%struct.A* %1, i32 1)
#2
%inalloca.save.i = call i8* @llvm.stacksave()
%argmem.i = alloca inalloca <{ i32, %struct.A }>, align 4
%2 = getelementptr inbounds <{ i32, %struct.A }>, <{ i32, %struct.A }>*
%argmem.i, i32 0, i32 1
%call.i = invoke x86_thiscallcc %struct.A* @"??0A@@QAE at XZ"(%struct.A* %2)
to label %invoke.cont.i unwind label %catch.dispatch.i
catch.dispatch.i: ; preds = %for.body
%3 = catchswitch within none [label %catch.i] unwind label %ehcleanup
catch.i: ; preds = %catch.dispatch.i
%4 = catchpad within %3 [i8* null, i32 64, i8* null]
catchret from %4 to label %catchret.dest.i
catchret.dest.i: ; preds = %catch.i
br label %"?inner@@YAHXZ.exit"
invoke.cont.i: ; preds = %for.body
%5 = getelementptr inbounds <{ i32, %struct.A }>, <{ i32, %struct.A }>*
%argmem.i, i32 0, i32 0
store i32 1, i32* %5, align 4
call void @"?foo@@YAXHUA@@@Z"(<{ i32, %struct.A }>* inalloca %argmem.i) #2
call void @llvm.stackrestore(i8* %inalloca.save.i)
br label %"?inner@@YAHXZ.exit"
"?inner@@YAHXZ.exit": ; preds = %catchret.dest.i,
%invoke.cont.i
br label %invoke.cont
invoke.cont: ; preds =
%"?inner@@YAHXZ.exit"
%6 = getelementptr inbounds <{ i32, %struct.A }>, <{ i32, %struct.A }>*
%argmem, i32 0, i32 0
store i32 3, i32* %6, align 4
call void @"?foo@@YAXHUA@@@Z"(<{ i32, %struct.A }>* inalloca %argmem) #2
call void @llvm.stackrestore(i8* %inalloca.save)
br label %for.inc
for.inc: ; preds = %invoke.cont
%7 = load i32, i32* %i, align 4
%inc = add nsw i32 %7, 1
store i32 %inc, i32* %i, align 4
br label %for.cond
ehcleanup: ; preds = %catch.dispatch.i
%8 = cleanuppad within none []
call x86_thiscallcc void @"??1A@@QAE at XZ"(%struct.A* %1) #2 [ "funclet"(token
%8) ]
cleanupret from %8 unwind to caller
for.end: ; preds = %for.cond
ret void
}
```
Moving the `@llvm.stackrestore` in `invoke.cont.i` to instead be in
`catchret.dest.i` seems to fix this issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200618/4f4c65b4/attachment.html>
More information about the llvm-bugs
mailing list