r187374 - PR16715: Fix assert in verifier: only mark call to 'operator new' as 'builtin' if

Richard Smith richard at metafoo.co.uk
Fri Sep 6 17:28:44 PDT 2013


On Sun, Sep 1, 2013 at 2:15 PM, Nick Lewycky <nlewycky at google.com> wrote:

> On 15 August 2013 15:08, Eli Friedman <eli.friedman at gmail.com> wrote:
>
>> On Mon, Jul 29, 2013 at 2:30 PM, Richard Smith <richard at metafoo.co.uk>wrote:
>>
>>> On Mon, Jul 29, 2013 at 2:00 PM, Eli Friedman <eli.friedman at gmail.com>wrote:
>>>
>>>> On Mon, Jul 29, 2013 at 1:14 PM, Richard Smith
>>>> <richard-llvm at metafoo.co.uk> wrote:
>>>> > Author: rsmith
>>>> > Date: Mon Jul 29 15:14:16 2013
>>>> > New Revision: 187374
>>>> >
>>>> > URL: http://llvm.org/viewvc/llvm-project?rev=187374&view=rev
>>>> > Log:
>>>> > PR16715: Fix assert in verifier: only mark call to 'operator new' as
>>>> 'builtin' if
>>>> > corresponding 'operator new' was actually emitted as a function
>>>> marked 'nobuiltin'.
>>>>
>>>> There's a similar bug involving LTO; consider the following:
>>>>
>>>> a.cpp:
>>>> using size_t = decltype(sizeof(0));
>>>> void *operator new(size_t) __attribute__((alias("something")));
>>>>
>>>> b.cpp:
>>>> int *pr16715 = new int;
>>>>
>>>> If I link these two together with llvm-link, I get exactly the same
>>>> error.
>>>>
>>>> Overall, this seems like a very fragile constraint; maybe we can relax
>>>> it somehow?
>>>
>>>
>>> It would seem reasonable to me for the verifier to allow the 'builtin'
>>> attribute on calls to functions declared without 'nobuiltin'. Patch
>>> attached.
>>>
>>
>> Ping.
>>
>
> Ping?
>
> I just hit this exact problem, the proposed patch seems right to me.
> Please commit?
>

Thanks, committed in r190233. Sorry for the delay.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130906/e0acee9e/attachment.html>


More information about the llvm-commits mailing list