<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 - Optimizer bug for ARM v7"
href="https://bugs.llvm.org/show_bug.cgi?id=44747">44747</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Optimizer bug for ARM v7
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>8.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>release blocker
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>-New Bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>brianp@dashlogic.com
</td>
</tr>
<tr>
<th>CC</th>
<td>htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org, neeilans@live.com, richard-llvm@metafoo.co.uk
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=23078" name="attach_23078" title="Android Studio example project, screenshots, assembly review">attachment 23078</a> <a href="attachment.cgi?id=23078&action=edit" title="Android Studio example project, screenshots, assembly review">[details]</a></span>
Android Studio example project, screenshots, assembly review
During our work with the pixman graphics library, we've discovered an optimizer
bug that results in incorrect bit shift math. There are no compile time errors,
but the output result is completely incorrect at runtime.
My development environment is using Windows 10, Android Studio v3.5.3, Android
NDK v20.0.5594570, with Clang v8.0.7. This bug appears to only happen when
targeting armeabi-v7a for 32-bit Android with -O1 or higher, and not for
arm64-v8a or any x86 variant.
I've attached an Android Studio sample project demonstrating the error, as well
as screenshots shots showing the invalid math calculation. Looking at
android.c, lines 8 and 10 cause the issue, where lines 17 and 19 do not (since
they are not optimized due to the optnone attribute). The data ends up in the
wrong byte position.
After looking through the generated assembly, it appears to be generating an
orr instruction with an incorrect shift value. I've attached a short review
showing some of the assembly differences between optimized and unoptimized
versions.</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>