<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:james.molloy@arm.com" title="James Molloy <james.molloy@arm.com>"> <span class="fn">James Molloy</span></a>
</span> changed
<a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - Port big-endian support to ARM64"
href="http://llvm.org/bugs/show_bug.cgi?id=19400">bug 19400</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>RESOLVED
</td>
<td>REOPENED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>FIXED
</td>
<td>---
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - Port big-endian support to ARM64"
href="http://llvm.org/bugs/show_bug.cgi?id=19400#c2">Comment # 2</a>
on <a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - Port big-endian support to ARM64"
href="http://llvm.org/bugs/show_bug.cgi?id=19400">bug 19400</a>
from <span class="vcard"><a class="email" href="mailto:james.molloy@arm.com" title="James Molloy <james.molloy@arm.com>"> <span class="fn">James Molloy</span></a>
</span></b>
<pre>A rather nasty issue regarding GCC incompatibility has been discovered, that
makes it necessary to reopen this issue.
During a discussion with the GCC folks, two faults in Clang were identified:
# The lane index to the lane-based vector intrinsics (such as vget_lane) is
being treated as the logical lane, not the architectural lane. Richard Earnshaw
has confirmed that it should be the architectural lane "as if" loaded by LDR.
# The LD1 intrinsic is a user override and the compiler should not undo the
LD1. The LD1 intrinsic is lowered to a normal LOAD node, so the compiler treats
it like any load and ensures it acts as if the load had been performed by LDR.
But LD1 should override this behaviour, and the load should be performed as if
it were loaded with LD1, not LDR.
Also of note is that the GCC vector extension initializer list syntax:
uint32x2_t x = {0, 1};
Is not allowed to be mixed with NEON intrinsics. Clang should warn about this.</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>