<p dir="ltr">I seem to recall discussing this before - is there an existing llvm bug filed, another email thread or something (or perhaps it was just an IRC conversation)? It would be good to keep all the discussion together or at least reference the prior (llvm community) discussion.</p>
<p dir="ltr">Have you tried applying your suggested patch? I assume you meant to suggest replacing/modifying the existing ctor (to take non-const ref) rather than adding another?</p>
<p dir="ltr">I'd assume that causes a lot of build failures as we probably rely on binding temporaries to ArrayRef's in many places correctly (most ArrayRef's are temporaries, not local variables).</p>
<p dir="ltr">I think in the previous discussion I suggested we might just want to make a practice of treating named/local (not parameter) ArrayRef's with greater suspicion, the same way we do for twine, but I'm not sure.</p>
<p dir="ltr">We could move this ctor into a factory function (and/or just make the CTor private and friend the makeArrayRef helper for this case) to make it more obvious/easier to find bad call sites. But it would be helpful to have the context of the prior discussion to continue from there.</p>
<div class="gmail_quote">On Aug 19, 2014 11:18 PM, "Joey Ye" <<a href="mailto:joey.ye.cc@gmail.com">joey.ye.cc@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Analyzing why GCC failed to build LLVM recently, one root cause lies<br>
in definition of ArrayRef:<br>
// ArrayRef.h:<br>
ArrayRef(const T &OneElt) : Data(&OneElt), Length(1) {}<br>
<br>
Here address of const reference is taken and stored to an object. It<br>
is believed that live range of const reference is only at the function<br>
call site, escaping of its address to an object with a longer live<br>
range is invalid. Referring to the case and discussion here:<br>
<a href="https://gcc.gnu.org/ml/gcc/2014-08/msg00173.html" target="_blank">https://gcc.gnu.org/ml/gcc/2014-08/msg00173.html</a><br>
<br>
So I would suggest to fix ArrayRef. Adding a non-const version of<br>
constructor should work, but it still leaves the vulnerability in<br>
const version, which I'd expect on people in the community to work out<br>
a solution.<br>
ArrayRef(T &OneElt) : Data(&OneElt), Length(1) {}<br>
<br>
<br>
Thanks,<br>
Joey<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div>