<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 - Invalid codegen when comparing pointer to one past the end and then dereferencing that pointer"
href="https://bugs.llvm.org/show_bug.cgi?id=52570">52570</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Invalid codegen when comparing pointer to one past the end and then dereferencing that pointer
</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>Linux
</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>C
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>gabravier@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>blitzrakete@gmail.com, dgregor@apple.com, erik.pilkington@gmail.com, llvm-bugs@lists.llvm.org, richard-llvm@metafoo.co.uk
</td>
</tr></table>
<p>
<div>
<pre>extern int x[1], y;
int f(int *p, int *q) {
*q = y;
if (p == (x + 1)) {
*p = 2;
return y;
}
return 0;
}
LLVM trunk currently outputs the following code with -O3 -mtune=znver3 (without
it it outputs correct code but I'm pretty sure it still makes the same wrong
assumption about the value of `p`):
f:
mov eax, dword ptr [rip + y]
mov dword ptr [rsi], eax
xor eax, eax
cmp rdi, offset x+4
je .LBB0_1
ret
.LBB0_1:
mov eax, dword ptr [rip + y]
mov dword ptr [rip + x+4], 2
ret
Which is incorrect because `p` could point to `y`, for example if `f` was
called as such:
int whatever;
f(&y, &whatever);
and `y` could happen to be located in memory right after `x`.
Also, although the comparison's result is unspecified, this still means only
two results are possible according to the standard:
- if `p == (x + 1)` results in `false`, then the result of `f` is 0
- if `p == (x + 1)` results in `true`, then the result of `f` is 2 since we do
`*p = 2` and `p` points to `y`
LLVM's optimization makes it so the result can also be the previous value of
`y`, which could be something else than 0 or 2.
It seems that LLVM assumes that because `p == (x + 1)` it can replace all
occurences of `p` with `x + 1` without any regard to provenance, and doing that
change manually would indeed mean the `return y;` could be optimized to use the
previous store (and the store to `x + 1` would be UB, too...), but this isn't
the case here: `p` could simultaneously validly point to `y` and be equal to `x
+ 1`.
Godbolt link: <a href="https://godbolt.org/z/v73ME48qd">https://godbolt.org/z/v73ME48qd</a></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>