<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 11 April 2017 at 18:16, Daniel Berlin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The corresponding line does not exist, and it is in fact, wrong :)<div><br></div><div>C11 says nothing like that.</div><div>C++14 says:</div><div>"The lifetime of an object of type T begins when:</div><div>— storage with the proper alignment and size for type T is obtained, and — if the object has non-trivial initialization, its initialization is complete.</div><div>The lifetime of an object of type T ends when:</div><div>— if T is a class type with a non-trivial destructor (12.4), the destructor call starts, or</div><div>— the storage which the object occupies is reused or released."</div><div><br></div><div>it also says:<br>"If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if:</div></div></blockquote><div><br></div><div><div>This wording describes what happens if you, for instance, placement new over an existing object. It is not intended to cover the case where you happen to reallocate storage you previously freed; see below for the rule on that case.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>...</div><div>a bunch of conditions".</div><div><br></div><div>Which makes it even worse because they become aliasing again.</div></div></blockquote><div><br></div><div>I believe this is the portion of the C++ standard you're looking for: [basic.stc]/4:</div><div><br></div><div>"When the end of the duration of a region of storage is reached, the values of all pointers representing the address of any part of that region of storage become invalid pointer values (6.9.2). Indirection through an invalid pointer value and passing an invalid pointer value to a deallocation function have undefined behavior. Any other use of an invalid pointer value has implementation-defined behavior."</div><div><br></div><div>(In C++14 and before, this was [basic.dynamic.deallocation]p4 and only applied to the effects of invoking 'operator delete', but we added the above wording as a defect resolution so it's intended to apply retroactively.)</div><div><br></div><div>So the comparison in the source program has UB, and the loop unswitching transformation is therefore invalid as an operation on C++ programs. (I don't think this observation helps, though, since we -- presumably -- want the transformation to be valid as an operation on LLVM IR...)<br></div><div><br></div><div>It seems to me that there are two ways of thinking about this: either the value of a pointer in IR is richer than its bit sequence, in which case replacing p1 with p0 in a block predicated by p0 == p1 is an incorrect transformation if you cannot prove that one pointer was based on the other, or the value of a pointer in IR is exactly its bit sequence, in which case the code performing the transformation incorrectly updated the IR and a correct transformation would need to somehow remove the noalias from the malloc calls. The C++ object model formally takes the former standpoint; its pointers notionally point to objects, which are abstract entities occupying storage, rather than pointing to the storage itself.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail-h5">On Tue, Apr 11, 2017 at 5:09 PM, Flamedoge via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr">I don't know when this was added on cppreference but <br><br>> <span style="color:rgb(0,0,0);font-family:dejavusans,"dejavu sans",arial,sans-serif;font-size:12.8px">The behavior is undefined if after </span><code style="color:rgb(0,0,0);font-size:12.8px;font-family:dejavusansmono,"dejavu sans mono",courier,monospace">free()</code><span style="color:rgb(0,0,0);font-family:dejavusans,"dejavu sans",arial,sans-serif;font-size:12.8px"> returns, an access is made through the pointer </span><code style="color:rgb(0,0,0);font-size:12.8px;font-family:dejavusansmono,"dejavu sans mono",courier,monospace">ptr</code><span style="color:rgb(0,0,0);font-family:dejavusans,"dejavu sans",arial,sans-serif;font-size:12.8px"> (unless another allocation function happened to result in a pointer value equal to </span><code style="color:rgb(0,0,0);font-size:12.8px;font-family:dejavusansmono,"dejavu sans mono",courier,monospace">ptr</code><span style="color:rgb(0,0,0);font-family:dejavusans,"dejavu sans",arial,sans-serif;font-size:12.8px">)<br><br>This seems to suggest that there is no UB... However, I couldn't find the corresponding line or relevant part on latest C std, </span><font color="#000000" face="dejavusans, dejavu sans, arial, sans-serif"><span style="font-size:12.8px"><a href="http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf" target="_blank">http://www.open-std.org/j<wbr>tc1/sc22/WG14/www/docs/n1570.p<wbr>df</a></span></font><div><font color="#000000" face="dejavusans, dejavu sans, arial, sans-serif"><span style="font-size:12.8px"><br></span></font></div><div><font color="#000000" face="dejavusans, dejavu sans, arial, sans-serif"><span style="font-size:12.8px">Regards,</span></font></div><div><font color="#000000" face="dejavusans, dejavu sans, arial, sans-serif"><span style="font-size:12.8px">Kevin</span></font></div></div><div class="gmail-m_5097885098490580088HOEnZb"><div class="gmail-m_5097885098490580088h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 11, 2017 at 4:27 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.co<wbr>m</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Kevin,<br>
<span><br>
On April 11, 2017 at 4:14:14 PM, Flamedoge (<a href="mailto:code.kchoi@gmail.com" target="_blank">code.kchoi@gmail.com</a>) wrote:<br>
> So only "non-freed" malloc pointers are No-Alias which makes it<br>
> flow-sensitive. There is no reason why malloc couldn't return previously<br>
> freed location.<br>
<br>
</span>Yes.<br>
<br>
Talking to Nick Lewycky on IRC, I figured out a shorter way of saying<br>
what I wanted to say.  We know that programs like this are UB in C:<br>
<br>
p0 = malloc();<br>
free(p0);<br>
p1 = malloc();<br>
if (p0 == p1) {<br>
  int v = *p0; // Semantically free'ed but bitwise equal to an allocated value<br>
}<br>
<br>
and we relied on them having UB when marking malloc's return value as noalias.<br>
<br>
However, we can end up in cases like the above by applying<br>
loop-unswitch + GVN to well defined C programs.<br>
<span class="gmail-m_5097885098490580088m_5477390877775861779HOEnZb"><font color="#888888"><br>
-- Sanjoy<br>
</font></span></blockquote></div><br></div>
</div></div><br></div></div><span class="gmail-">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>