<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:john.brawn.123@gmail.com" title="John Brawn <john.brawn.123@gmail.com>"> <span class="fn">John Brawn</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Thumb1 mode generating illegal add instructions"
href="https://llvm.org/bugs/show_bug.cgi?id=7496">bug 7496</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>FIXED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Thumb1 mode generating illegal add instructions"
href="https://llvm.org/bugs/show_bug.cgi?id=7496#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Thumb1 mode generating illegal add instructions"
href="https://llvm.org/bugs/show_bug.cgi?id=7496">bug 7496</a>
from <span class="vcard"><a class="email" href="mailto:john.brawn.123@gmail.com" title="John Brawn <john.brawn.123@gmail.com>"> <span class="fn">John Brawn</span></a>
</span></b>
<pre>It looks like LLVM 2.7 is where this bug occurred, and the problem was
Thumb1RegisterInfo::rewriteFrameIndex using tADDhirr without checking if
FrameReg was a high register (probably assuming it was SP). In current trunk
the equivalent code path goes through emitThumbRegPlusImmInReg which dutifully
checks if the registers are high and uses tADDrr if not.
I'm pretty sure now that there's no way for tADDhirr without high registers to
be generated when it shouldn't - it's generated only by the aforementioned
emitThumbRegPlusImmInReg and by Thumb2SizeReduction, and when we have Thumb2 we
can use low registers in that instruction.
We still have the problem that MC allows the instruction when it shouldn't, but
that's less of a problem and only really affects disassembly (ARMAsmParser has
its own check to ensure it isn't allowed when it shouldn't be when assembling).
So I think we can say this bug no longer occurs.</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>