<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - [StackColoring] Need Conservatively merge point pV = &(&Variable) in catch(Variable)"
href="https://bugs.llvm.org/show_bug.cgi?id=48064">48064</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[StackColoring] Need Conservatively merge point pV = &(&Variable) in catch(Variable)
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Common Code Generator Code
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>xiang1.zhang@intel.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>We need conservatively merge pV = &(&Variable) for catch(Variable), EH libs may
write the catch value and return the Point (Type**) pV back.
This Point may be dangerously over written due to some work of objects'
destructor in try block. (The destructor may work after EH written)
In fact, for the catch point pV, there is usually a very long life range
guarded with TIME_START and TIME_END (usually almost through the whole
program),
but there is an potion "-stackcoloring-lifetime-start-on-first-use" which will
cut it shorter.
We should let pV conservatively use its TIME_START and TIME_END as its
live-range, not affected by the option
"-stackcoloring-lifetime-start-on-first-use"
We find this bug in a big win32 project, now the following case can reproduce.
Compile with: clang-cl -m32 -O2 -EHs test.cpp
test.cpp:
__attribute__((noinline,nothrow,weak)) void escape(int *p) { }
struct object {
int i;
object() {
i = 1;
}
~object() {
// if "object" and "exp" are assigned to the same slot,
// this assign will corrupt "exp".
i = 9999;
escape(&i);
}
};
inline void throwit() { throw 999; }
volatile int v;
inline void func() {
try {
object o;
throwit();
}
// "exp" is written by the OS when the "throw" occurs.
// Then the destructor is called, and the store-assign
// clobbers the value of "exp".
// The dereference of "exp" (with value 9999) causes a crash.
catch (int &exp) {
v = exp;
}
}
int main() {
func();
return 0;
}
//////////////////
Now we already have a patch to handle this. (<a href="https://reviews.llvm.org/D86673">https://reviews.llvm.org/D86673</a>)</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>