Page MenuHomePhabricator

beccadax (Becca Royal-Gordon)
User

Projects

User does not belong to any projects.

User Details

User Since
Aug 26 2018, 5:22 PM (137 w, 2 d)

Recent Activity

Feb 26 2021

bkramer renamed beccadax from brentdax to beccadax.
Feb 26 2021, 1:41 AM

Feb 24 2021

beccadax updated beccadax.
Feb 24 2021, 4:54 PM

Feb 23 2021

beccadax added inline comments to D94950: [clang][lex] Speculative fix for buffer overrun on raw string parse.
Feb 23 2021, 2:05 PM · Restricted Project
beccadax accepted D94950: [clang][lex] Speculative fix for buffer overrun on raw string parse.

Looks good. Thanks for implementing this!

Feb 23 2021, 1:58 PM · Restricted Project

Aug 16 2019

beccadax added a comment to D66330: Fix use-after-free in CodeGenPrepare.

@spatel @lebedev.ri I don't have commit access, so could one of you commit this when you think it's had enough time for comments?

Aug 16 2019, 1:48 PM · Restricted Project
beccadax added inline comments to D66330: Fix use-after-free in CodeGenPrepare.
Aug 16 2019, 1:43 PM · Restricted Project
beccadax added a comment to D66330: Fix use-after-free in CodeGenPrepare.

I've filed a bug at https://bugs.llvm.org/show_bug.cgi?id=43021.

Aug 16 2019, 11:33 AM · Restricted Project

Aug 15 2019

beccadax added reviewers for D66330: Fix use-after-free in CodeGenPrepare: spatel, lebedev.ri, RKSimon.
Aug 15 2019, 7:47 PM · Restricted Project
beccadax created D66330: Fix use-after-free in CodeGenPrepare.
Aug 15 2019, 7:41 PM · Restricted Project

Sep 6 2018

beccadax added a comment to D51317: Handle BumpPtrAllocator::Allocate(0) without undefined behavior.

(Some emails I sent don't seem to have gotten through.)

Sep 6 2018, 1:01 PM

Sep 2 2018

beccadax added a comment to D51317: Handle BumpPtrAllocator::Allocate(0) without undefined behavior.

@hans So do you think it's okay to go at this point, or do you want more benchmarking?

Sep 2 2018, 11:37 AM

Aug 31 2018

beccadax retitled D51317: Handle BumpPtrAllocator::Allocate(0) without undefined behavior from Keep BumpPtrAllocator::Allocate(0) from returning nullptr to Handle BumpPtrAllocator::Allocate(0) without undefined behavior.
Aug 31 2018, 1:51 AM
beccadax updated the diff for D51317: Handle BumpPtrAllocator::Allocate(0) without undefined behavior.

I think the best solution is to make BumpPtrAllocator::Allocate() consistently return nullptr for zero-size allocations.
Zero-size allocations are already extremely common in the wild; allocating space unnecessarily just imposes a softer
requirement for users to avoid doing it; a guard page is massive overkill; the noalias guarantee seems more valuable;
and users already had to be prepared to occasionally receive nullptr returns for zero-size allocations anyway.

Aug 31 2018, 1:46 AM

Aug 30 2018

beccadax added a comment to D51317: Handle BumpPtrAllocator::Allocate(0) without undefined behavior.

I locally tried adding an assert(Size > 0), but also making Allocate<T>()--which doesn't have any of these attributes--return nullptr for zero elements. This design broke 1,060 tests, mostly in clang but a few in LLVM too. So asserting is going to break a ton of code. (I also tried making it waste some space, but only if you don't go through Allocate<T>()—this worked fine.)

Aug 30 2018, 4:56 PM

Aug 29 2018

beccadax planned changes to D51317: Handle BumpPtrAllocator::Allocate(0) without undefined behavior.

If we end up in a place where you’d still want to avoid empty allocations, then I think we should go back to the previous implementation. Current clients are already receiving duplicate addresses, so this won’t cause any new bugs. We can clearly document the behavior.

Aug 29 2018, 4:09 PM

Aug 28 2018

beccadax updated the diff for D51317: Handle BumpPtrAllocator::Allocate(0) without undefined behavior.

Reimplemented to return a unique address for each zero-size allocation.

Aug 28 2018, 11:14 AM
beccadax added a comment to D51317: Handle BumpPtrAllocator::Allocate(0) without undefined behavior.

Zero-size allocations usually happen when an array or string happens to have zero elements. I'm trying to clean up UBSan failures in the Swift compiler, and there are several places where this happens there, such as when an array of code completions has no results. We could guard every call like this with an if/else, or we could wrap llvm::BumpPtrAllocator with something that has the if/else statements, or we could change llvm::BumpPtrAllocator so that it handles zero-size allocations without breaking its own contract.

Aug 28 2018, 2:28 AM

Aug 27 2018

beccadax created D51317: Handle BumpPtrAllocator::Allocate(0) without undefined behavior.
Aug 27 2018, 12:12 PM