[polly] r246396 - Do not store into a temporary twine

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 31 09:57:59 PDT 2015


On Mon, Aug 31, 2015 at 9:39 AM, Tobias Grosser <tobias at grosser.es> wrote:

> On 08/31/2015 06:04 PM, David Blaikie wrote:
>
>> On Sun, Aug 30, 2015 at 12:51 PM, Tobias Grosser via llvm-commits <
>> llvm-commits at lists.llvm.org> wrote:
>>
>> Author: grosser
>>> Date: Sun Aug 30 14:51:01 2015
>>> New Revision: 246396
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=246396&view=rev
>>> Log:
>>> Do not store into a temporary twine
>>>
>>> For some reason, this causes memory corruption issues. Let's just avoid
>>> it.
>>>
>>>
>> Twines are not designed to be named, as such.
>>
>> A Twine expresion stores references to Twine subexpressions that are local
>> to the C++ full expression - once you are outside that full expression
>> those references are dangling (as the subexpression Twines are out of
>> scope).
>>
>
> Thanks for explaining. I think I run into a similar issue a couple of
> months
> ago. Unfortunately the code that showed the bug does not really give any
> hint
> that this is indeed problematic:
>
> auto Name = Address->getName() + ".reload";
>
> I suppose there is no easy way for us to make this cause a compiler bug or
> trigger an assert?
>

Not really, no. UBSan could do some lifetime management checking, but even
that's pretty tricky.

Maybe ASan's (or MSan, is it?) stack lifetime checkers? (I forget what
they're called, but I think there's some prototype support for this... )


>
> Best,
> Tobias
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150831/273e1757/attachment.html>


More information about the llvm-commits mailing list