Displaying 20 results from an estimated 5000 matches similar to: "UBSan, StringRef and Allocator.h"
2016 Mar 23
0
UBSan, StringRef and Allocator.h
On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi all
>
> (No idea if I have the correct audience. Please CC more people as needed).
>
> I have an UBSan failure in BumpPtrAllocatorImpl.Allocate.
>
> The problem is that lld requests that we StringRef::copy an empty string.
> This passes a length of 0 to a
2016 Mar 23
3
UBSan, StringRef and Allocator.h
> On Mar 22, 2016, at 5:35 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote:
> Hi all
>
> (No idea if I have the correct audience. Please CC more people as needed).
>
> I have an UBSan failure in
2016 Mar 23
0
UBSan, StringRef and Allocator.h
On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com> wrote:
> Hi all
>
> (No idea if I have the correct audience. Please CC more people as needed).
>
> I have an UBSan failure in BumpPtrAllocatorImpl.Allocate.
>
> The problem is that lld requests that we StringRef::copy an empty string.
> This passes a length of 0 to a BumpPtrAllocator. The
2016 Mar 28
2
UBSan, StringRef and Allocator.h
FWIW, I agree with Mehdi that we should just assert that our types don't
get called with size zero.
That said, I don't think we can be terribly cavalier with what we expect
from standard allocator types, operator new, or malloc. And so I would
expect LLVM_ATTRIBUTE_RETURNS_NOALIAS to not imply NONNULL, and while it
seems reasonable to put NONNULL on *our* allocate function because of the
2016 Mar 23
0
UBSan, StringRef and Allocator.h
> On Mar 22, 2016, at 5:39 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
>>
>> On Mar 22, 2016, at 5:35 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
>>
>>
>>
>> On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at
2016 Mar 29
2
UBSan, StringRef and Allocator.h
> On Mar 28, 2016, at 6:02 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
>>
>> On Mar 28, 2016, at 3:12 PM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
>>
>> FWIW, I agree with Mehdi that we should just assert that our types don't get called with size zero.
> Yeah, I agree. I’ve
2016 Mar 29
0
UBSan, StringRef and Allocator.h
> On Mar 28, 2016, at 3:12 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
> FWIW, I agree with Mehdi that we should just assert that our types don't get called with size zero.
Yeah, I agree. I’ve tried running the tests with the assert in place and there’s about 1000 failures across llvm/clang. I’ll see what I can fix as I would like to get these to behave. There
2016 Mar 29
0
UBSan, StringRef and Allocator.h
On 03/29/2016 01:59 PM, Pete Cooper via llvm-dev wrote:
>
>> On Mar 28, 2016, at 6:02 PM, Pete Cooper via llvm-dev
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>>>
>>> On Mar 28, 2016, at 3:12 PM, Chandler Carruth <chandlerc at google.com
>>> <mailto:chandlerc at google.com>> wrote:
2016 Mar 30
1
UBSan, StringRef and Allocator.h
> On Mar 29, 2016, at 4:45 PM, Philip Reames <listmail at philipreames.com> wrote:
>
>
>
> On 03/29/2016 01:59 PM, Pete Cooper via llvm-dev wrote:
>>
>>> On Mar 28, 2016, at 6:02 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>
>>>>
>>>> On Mar 28, 2016, at
2016 Mar 23
1
UBSan, StringRef and Allocator.h
> On Mar 22, 2016, at 5:57 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
>
> On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> Hi all
>>
>> (No idea if I have the correct audience. Please CC more people as needed).
>>
>> I have an UBSan
2006 May 14
2
[LLVMdev] __main() function and AliasSet
In a code segment of my pass plugin, I try to gather AliasSets for all StoreInst, LoadInst and CallInst instructions in a function.
Some behaviors of the pass puzzled me.
Below is the *.ll of the test program which I run the pass on,
it was get with "llvm-gcc -Wl,--disable-opt" from a rather simple *.c program.
----------------------------------
; ModuleID = 'ptralias.bc'
2015 Oct 19
3
Managed Languages BOF @ Dev Meeting
On 18 Oct 2015, at 23:08, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
>
> Supporting only basic block level granularity for "try ranges" may not
> be sufficient for Java -- if a basic block has more than one null check
> in it then throwing the NullPtrException for the first null check (if
> it fails) is semantically different from throwing the
2006 May 14
0
[LLVMdev] Re: __main() function and AliasSet
Oh, I appologize that I should not have asked about __main() ---- it appears
in FAQ.
But the question remains that why call to __main() can alias stack location?
I think the memory location pointed by data_X pointers are not visible to
__main().
In comparison, calls to printf() do not have similar effect.
On 5/14/06, Nai Xia <nelson.xia at gmail.com> wrote:
>
> In a code segment of
2006 May 15
2
[LLVMdev] Re: __main() function and AliasSet
Hi Chris,
I took a haste look at the "Points-to Analysis in Almost Linear Time" by Steens , your PHD thesis
and SteensGaard.cpp in LLVM this afternoon.
So I think:
1. Actually the basic algorithm described originally by SteensGaard does not provide MOD/REF information for functions.
2. The context insensitive part of Data Structure Analysis (LocalAnalysis) can be deemed as
an
2016 Jul 15
2
RFC: Strong GC References in LLVM
On Fri, Jul 15, 2016 at 2:30 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:
> Hi Daniel,
>
> Daniel Berlin wrote:
> > However, I didn't quite understand your point about may-throw -- how
> > is may-throw different from a generic side-effect (volatile store,
> > syscall etc.)? All of those can't be hoisted or sunk -- we have to
>
2006 May 17
2
[LLVMdev] Re: __main() function and AliasSet
On Tuesday 16 May 2006 03:19, Chris Lattner wrote:
> On Mon, 15 May 2006, Nai Xia wrote:
>
> > In other words, if I only use -steens-aa and the data_XXXs are all
> > external global variables( and so inComplete ),
>
> Sounds right!
>
> > the call to printf will
> > make the same effect, which I have tested it.
> >
> > Am I right ? :)
>
2015 Oct 18
3
Managed Languages BOF @ Dev Meeting
I won’t be able to attend, but I’d be interested in hearing if any conclusions are reached on several of these topics:
> On 16 Oct 2015, at 21:27, Joe Ranieri via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> - Dealing with the explosion of basic blocks that come up with
> languages where almost every function call, implicit and explicit, can
> raise exceptions.
This
2006 May 17
0
[LLVMdev] Re: __main() function and AliasSet
On Wed, 17 May 2006, Nai Xia wrote:
> Unfortunately, I did not locate the lines in steens-aa for "printf" special case.
> In ds-aa, I found the lines below:
Right, steens-aa and ds-aa share code for "local analysis", they just
stitch it together into an interprocedural analysis in different ways.
The code below is used for steens-aa.
>
2006 May 15
0
[LLVMdev] Re: __main() function and AliasSet
On Mon, 15 May 2006, Nai Xia wrote:
> In other words, if I only use -steens-aa and the data_XXXs are all
> external global variables( and so inComplete ),
Sounds right!
> the call to printf will
> make the same effect, which I have tested it.
>
> Am I right ? :)
If you've tested it then, yes you're right :). I haven't played with this
stuff for a long time,
2015 May 11
2
[LLVMdev] Bug in Support/Allocator.h
Hi,
llvm::BumpPtrAllocatorImpl::Reset() looks like it has a bug.
There is this check at the top:
if (Slabs.empty())
return;
But what if you don't have any normal Slabs allocated but only
CustomSizedSlabs.
I think this should be:
if (Slabs.empty() && CustomSizedSlabs.empty())
return;