<div dir="ltr"><div><div><div><div>I think David is referring this thread:<br><a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074909.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074909.html</a><br>
<br></div>I also tried building with the suggested patch (replacing/modifying the existing ctor (to take non-const ref) ) and this indeed results in plenty of build errors. I tried fixing them for a few hours but haven't seen light at the end of the tunnel.<br>
</div><br></div>Best regards,<br></div>Andy<br><div><div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-08-21 9:38 GMT+02:00 Justin Bogner <span dir="ltr"><<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> writes:<br>

> I seem to recall discussing this before - is there an existing llvm<br>
> bug filed, another email thread or something (or perhaps it was just<br>
> an IRC conversation)? It would be good to keep all the discussion<br>
> together or at least reference the prior (llvm community) discussion.<br>
<br>
</div>I'm not sure if it's been discussed before, but it's led to issues as<br>
recently as a couple of weeks ago:<br>
<br>
    <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140804/229557.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140804/229557.html</a><br>
<br>
I certainly think it's worthwhile to make this API safer, or at least to<br>
document the caveats in how it can safely be used.<br>
<div class=""><div class="h5"><br>
> Have you tried applying your suggested patch? I assume you meant to suggest<br>
> replacing/modifying the existing ctor (to take non-const ref) rather than<br>
> adding another?<br>
><br>
> I'd assume that causes a lot of build failures as we probably rely on binding<br>
> temporaries to ArrayRef's in many places correctly (most ArrayRef's are<br>
> temporaries, not local variables).<br>
><br>
> I think in the previous discussion I suggested we might just want to make a<br>
> practice of treating named/local (not parameter) ArrayRef's with greater<br>
> suspicion, the same way we do for twine, but I'm not sure.<br>
><br>
> We could move this ctor into a factory function (and/or just make the CTor<br>
> private and friend the makeArrayRef helper for this case) to make it more<br>
> obvious/easier to find bad call sites. But it would be helpful to have the<br>
> context of the prior discussion to continue from there.<br>
><br>
> 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>
><br>
>     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>
>     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>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         http://llvm.cs.uiuc.eduhttp://<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>

<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>
</div></div></blockquote></div><br></div></div></div></div></div></div>