<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 - clang-cl.exe try/catch wrong asm"
href="https://bugs.llvm.org/show_bug.cgi?id=45163">45163</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>clang-cl.exe try/catch wrong asm
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>9.0
</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>LLVM Codegen
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>Danczyk_Josh_R@cat.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org, neeilans@live.com, richard-llvm@metafoo.co.uk
</td>
</tr></table>
<p>
<div>
<pre>I have tried to recreate this bug with a simple example, but the compiler
outsmarts me at every turn. Instead I'll describe what I think is going on.
This is x64 on Windows 10 using clang-cl.exe
Consider this pseudo-code:
void f() {
do_something_that_involves_a_lot_of_xmm_registers;
try {
some_other_function();
} catch (const SomeExceptionType& e) {
handle_exception;
}
}
The prologue of f() pushes a number of registers to stack. It also specifically
writes xmm6 to the stack, which as I read from the Microsoft ABI is
non-volatile. The epilogue of f() pops everything and restore xmm6. Everything
looks fine.
Now the problem. When some_other_function() throws SomeExceptionType the
exception handler is invoked and after several calls we end up in the catch
statement -- as a function. Something like
f()->some_other_function()->exception_handler()->catch_statement(). The
prologue of this catch statement "function" is a carbon copy of f()'s prologue,
meaning we push all the registers and store xmm6 to the stack -- even though
these registers are not used. But we store to the *exact memory location* that
f() originally stored. Since xmm6 was damaged during
do_something_that_involves_a_lot_of_xmm_registers the damaged value is written.
Then when we leave f() we restore the damaged xmm6, leaving f()'s caller in a
broken state.
I "solved" the issue by placing the try/catch in a [[gnu::noinline]] function.
This works because this code doesn't directly do any floating point and
therefore doesn't need to save/restore xmm6.</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>