search for: llvm_attribute_returns_noalia

...happened to not have anything allocated yet so the CurPtr is nullptr, but given that we need 0 space we think we have enough space and return an allocation of size 0 at address nullptr. This therefore returns nullptr from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL and LLVM_ATTRIBUTE_RETURNS_NOALIAS, both of which aren’t true in this case. To put this in code, if I have BumpPtrAllocator allocator; StringRef s; s.copy(allocator); then i’m going to allocate 0 bytes in the allocator and get a StringRef(nullptr, 0). Its a valid StringRef, but an UBSan failures in the allocator. Lang and I lo...

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 assert and the fact that we assume the underlying allocation routine never produces a null, it doesn't seem reasonable for any old function with NOALIAS to have NONNULL inferred. -Chan...

...happened to not have anything allocated yet so the CurPtr is nullptr, but given that we need 0 space we think we have enough space and return an allocation of size 0 at address nullptr. This therefore returns nullptr from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL and LLVM_ATTRIBUTE_RETURNS_NOALIAS, both of which aren’t true in this case. > > To put this in code, if I have > > BumpPtrAllocator allocator; > StringRef s; > s.copy(allocator); > > then i’m going to allocate 0 bytes in the allocator and get a StringRef(nullptr, 0). Its a valid StringRef, but an UBSan f...

...lvm/clang. I’ll see what I can fix as I would like to get these to behave. There may be actual logic errors in some of these cases. > > 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 assert and the fact that we assume the underlying allocation routine never produces a null, it doesn't seem reasonable for any old function with NOALIAS to have NONNULL inferred. I agre...

...neMemOperand’s, despite being marked as loading from memory. Will file a PR so that we can track some of these issues. Pete >> >> 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 assert and the fact that we assume the underlying allocation routine never produces a null, it doesn't seem reasonable for any old function with NOALIAS to have NONNULL inferred. > I...

...happened to not have anything allocated yet so the CurPtr is nullptr, but given that we need 0 space we think we have enough space and return an allocation of size 0 at address nullptr. This therefore returns nullptr from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL and LLVM_ATTRIBUTE_RETURNS_NOALIAS, both of which aren’t true in this case. >> >> To put this in code, if I have >> >> BumpPtrAllocator allocator; >> StringRef s; >> s.copy(allocator); >> >> then i’m going to allocate 0 bytes in the allocator and get a StringRef(nullptr, 0). Its a...

...made some forward progress, but there's a lot of work left to do here. > > Pete >>> >>> 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 assert and the fact that we assume >>> the underlying allocation routine never produces a null, it doesn't >>> seem reasonable for any ol...

...e anything allocated yet so the CurPtr is nullptr, but > given that we need 0 space we think we have enough space and return an > allocation of size 0 at address nullptr. This therefore returns nullptr > from Allocate, but that method is marked > with LLVM_ATTRIBUTE_RETURNS_NONNULL and LLVM_ATTRIBUTE_RETURNS_NOALIAS, > both of which aren’t true in this case. > > To put this in code, if I have > > BumpPtrAllocator allocator; > StringRef s; > s.copy(allocator); > > > then i’m going to allocate 0 bytes in the allocator and get a > StringRef(nullptr, 0). Its a valid StringRef, bu...

...thing I want to suggest without thinking of less invasive alternatives. Cheers, Pete >> >> Pete >>>> >>>> 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 assert and the fact that we assume the underlying allocation routine never produces a null, it doesn't seem reasonable for any old function with NOALIAS to have NONNULL inferred. >&g...

...e anything allocated yet so the CurPtr is nullptr, but > given that we need 0 space we think we have enough space and return an > allocation of size 0 at address nullptr. This therefore returns nullptr > from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL > and LLVM_ATTRIBUTE_RETURNS_NOALIAS, both of which aren’t true in this case. Why is noalias not valid here? I thought LLVM's notion of noalias was based on data dependence -- ptr_a does not alias ptr_b if a store to ptr_a does not have a data dependence with a load from ptr_b and vice versa (and for a zero-sized allocation the...

...ated yet so the CurPtr is nullptr, but >> given that we need 0 space we think we have enough space and return an >> allocation of size 0 at address nullptr. This therefore returns nullptr >> from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL >> and LLVM_ATTRIBUTE_RETURNS_NOALIAS, both of which aren’t true in this case. > > Why is noalias not valid here? > > I thought LLVM's notion of noalias was based on data dependence -- > ptr_a does not alias ptr_b if a store to ptr_a does not have a data > dependence with a load from ptr_b and vice versa (and f...