<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 - [ARM code-gen] Not passing all parameters in printf call"
href="https://bugs.llvm.org/show_bug.cgi?id=35728">35728</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[ARM code-gen] Not passing all parameters in printf call
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>4.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</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>andyg1001@hotmail.co.uk
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=19593" name="attach_19593" title="Assembly output generated for code sample">attachment 19593</a> <a href="attachment.cgi?id=19593&action=edit" title="Assembly output generated for code sample">[details]</a></span>
Assembly output generated for code sample
I actually stumbled across this while trying to determine a test-case to find
another problem.
The code is quite possibly undefined behaviour (it certainly produces very
different outcomes when compiled for x86 vs ARM). However, it seems to also
trigger a bug in the ARM code generator on clang 4.0. I don't have a more
recent build to hand, so I haven't been able to test that.
The sample code is:
int main()
{
const float f = 10.0f;
for (int i = 11; i < 15; ++i)
{
const unsigned u = f - i;
printf("A %i %i\n", i, u);
}
for (int i = 1; i < 15; ++i)
{
const unsigned u = f - i;
printf("B %i %i\n", i, u);
}
for (int i = 11; i < 15; ++i)
{
const unsigned u = f - i;
printf("C %i %i\n", i, u);
}
return 0;
}
Now, if I compile this for a Cortex-A9 ARM processor (-target
"arm-unknown-linux-gnueabihf" -mcpu="cortex-a9"), using clang-4.0.0 and
optimisation level 2, I get this output:
A 11 2127129340
A 12 1
A 13 1
A 14 1
B 1 9
B 2 8
B 3 7
B 4 6
B 5 5
B 6 4
B 7 3
B 8 2
B 9 1
B 10 0
B 11 1
B 12 1
B 13 1
B 14 1
C 11 1
C 12 1
C 13 1
C 14 1
Note that the first line changes every time the code is run.
GCC 4.8.5 for the same processor is more consistent and gives:
A 11 0
A 12 0
A 13 0
A 14 0
B 1 9
B 2 8
B 3 7
B 4 6
B 5 5
B 6 4
B 7 3
B 8 2
B 9 1
B 10 0
B 11 0
B 12 0
B 13 0
B 14 0
C 11 0
C 12 0
C 13 0
C 14 0
(Just for curiosities sake, on x86, you get negative numbers for i > 10 rather
than limiting to 0, and this is -- I assume -- the "undefined behaviour").
I have attached the assembly output from clang. In it you can see that the
compiler has unrolled all the loops, but doesn't give "r2" a value for any line
where i > 10.
Note that if the "unsigned" types are changed to "int" OR the "float" type is
changed to "int" or "unsigned", then "r2" is always given a value (and a
negative one for i > 10 like you get on x86 for the original code).</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>