<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:llvm@joakim.fea.st" title="llvm@joakim.fea.st">llvm@joakim.fea.st</a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - [Regression] GVN optimization pass since llvm 3.8 produces wrong IR in one case"
href="https://llvm.org/bugs/show_bug.cgi?id=28224">bug 28224</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>INVALID
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - [Regression] GVN optimization pass since llvm 3.8 produces wrong IR in one case"
href="https://llvm.org/bugs/show_bug.cgi?id=28224#c9">Comment # 9</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - [Regression] GVN optimization pass since llvm 3.8 produces wrong IR in one case"
href="https://llvm.org/bugs/show_bug.cgi?id=28224">bug 28224</a>
from <span class="vcard"><a class="email" href="mailto:llvm@joakim.fea.st" title="llvm@joakim.fea.st">llvm@joakim.fea.st</a>
</span></b>
<pre><span class="quote">> I guess what I am trying to say is that this bug has nothing to
> do with inlining: imagine that the code in imagine_shift was in
> main because it was written that way.</span >
I don't have to imagine it: I noted in my comment that when I replaced the
function with the exact same code, manual inlining essentially, clang warned
about that expression, while it did nothing if the code was in a separate
function.
Since I noted this behavior on the ldc forum, one of the ldc contributors
pointed me at this old llvm blog post, explaining why llvm doesn't try to warn
about such behavior:
<a href="http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html">http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html</a>
While there are a lot of arguments there, I don't find the reasoning that "we
simply don't have the internal tracking infrastructure to produce" usable error
messages that follow optimizations from the original code to be convincing. I
think that needs to be done.
Anyway, I suppose the usual argument is that the function is wrong given
certain input and it's not up to the optimizer to flag such bugs, but the code
should have been tested unoptimized to shake out such bugs first. I'll look
into why our debug-mode tests weren't catching this either, that's likely the
real reason this got through.
Of course, many people don't exhaustively test their code and it's going to
make matters worse for them when the llvm optimizer just removes it without a
warning.</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>