<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 - Incorrect result with inline asm and rev16"
href="https://bugs.llvm.org/show_bug.cgi?id=42044">42044</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Incorrect result with inline asm and rev16
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>3.8
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</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>noloader@gmail.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'm working on a Tinkerboard running Raspbian. It is a Cortex A-17 machine. It
has Clang 3.8 installed.
The following is producing incorrect results. I came across the case when
removing an uint32_t casts because it produced an extra uxth. I'm not sure if
this is expected or something is sideways.
$ cat test.cxx
#include <stdint.h>
uint16_t ByteReverse(uint16_t value)
{
uint16_t rvalue;
__asm__ ("rev16 %0, %1" : "=r" (rvalue) : "r" (value));
return rvalue;
}
int main(int argc, char* argv[])
{
uint16_t u = argc;
u = ByteReverse(u);
return u;
}
$ clang++ -O1 test.cxx -o test.exe
$ ./test.exe v v v v v
$ echo $?
0
I'm not sure what is going on since the rev16 is present:
$ clang++ -O1 test.cxx -c
$ objdump -d test.o
...
00000000 <_Z11ByteReverset>:
0: e6bf0fb0 rev16 r0, r0
4: e6ff0070 uxth r0, r0
8: e12fff1e bx lr
0000000c <main>:
c: e92d4800 push {fp, lr}
10: e1a0b00d mov fp, sp
14: e6ff0070 uxth r0, r0
18: ebfffffe bl 0 <_Z11ByteReverset>
1c: e8bd8800 pop {fp, pc}
According to the ARM manual, rev16 performs:
if ConditionPassed() then
EncodingSpecificOperations();
bits(32) result;
result<31:24> = R[m]<23:16>;
result<23:16> = R[m]<31:24>;
result<15:8> = R[m]<7:0>;
result<7:0> = R[m]<15:8>;
R[d] = result;
It does not appear a half word is jumping from lo to hi (or vice versa). The
result of interest should be located in either <15:0> or <31:16>, which is
where it was located before rev16.</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>