<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 - Clang vectorizer produces incorrect code on simple test"
href="https://bugs.llvm.org/show_bug.cgi?id=35743">35743</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Clang vectorizer produces incorrect code on simple test
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</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>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>max.kazantsev@azul.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Clang miscompiles the following function:
char foo(char c)
{
for (int i = 1; i < 193; i++) {
c &= (char) 1;
c += (char) 3;
}
return c;
}
Run 'clang -O2 -emit-llvm -g0'
(online compiler quick link: <a href="https://godbolt.org/g/Mpfbxp">https://godbolt.org/g/Mpfbxp</a>)
The IR on current trunk looks like this:
define signext i8 @foo(char)(i8 signext) local_unnamed_addr #0 {
%2 = insertelement <16 x i8> <i8 undef, i8 0, i8 0, i8 0, i8 0, i8 0, i8 0,
i8 0, i8 0, i8 0, i8 0, i8 0, i8 0, i8 0, i8 0, i8 0>, i8 %0, i32 0
%3 = and <16 x i8> %2, <i8 1, i8 1, i8 1, i8 1, i8 1, i8 1, i8 1, i8 1, i8 1,
i8 1, i8 1, i8 1, i8 1, i8 1, i8 1, i8 1>
%4 = icmp ne <16 x i8> %3, zeroinitializer
%5 = shufflevector <16 x i1> %4, <16 x i1> undef, <16 x i32> <i32 8, i32 9,
i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 undef, i32 undef, i32
undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%6 = xor <16 x i1> %4, %5
%7 = shufflevector <16 x i1> %6, <16 x i1> undef, <16 x i32> <i32 4, i32 5,
i32 6, i32 7, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef,
i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%8 = xor <16 x i1> %6, %7
%9 = shufflevector <16 x i1> %8, <16 x i1> undef, <16 x i32> <i32 2, i32 3,
i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef,
i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
%10 = xor <16 x i1> %8, %9
%11 = shufflevector <16 x i1> %10, <16 x i1> undef, <16 x i32> <i32 1, i32
undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32
undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32
undef>
%12 = xor <16 x i1> %10, %11
%13 = extractelement <16 x i1> %12, i32 0
%14 = zext i1 %13 to i8
ret i8 %14
}
As you can see, the returned value comes from i1 which is zexted to i8. So this
IR always returns 0 or 1, while the correct answer for this test is 3 or 4
depending on oddity of variable 'c'.
The issue is reproducible on trunk and have existed since version 3.8 where the
vectorization for this test was first applied. It seems that disabling
vectorization makes the issue gone.</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>