Updating diff to reflect memory leak fixes, using strategy from D86968 to use SpecificBumpPtrAllocator rather than BumpPtrAllocatotr.
Formatted and now superfluous comment removed.
than someone needs to commit it.
We also found an infinite loop triggered by this. Our repro is at https://bugs.chromium.org/p/chromium/issues/detail?id=1153398#c3
I'm guessing it is safe to ignore the unused function warnings?
Also, please respond to this:Happy to restrict to not using or defining any symbol and global variables and that everything else is UB. Would that be reasonable?
Do you still foresee the problematic behaviors you mentioned with these restrictions ?
Looking at CodeGenFunction::GenerateOpenMPCapturedVars, the condition if (!CurField->getType()->isAnyPointerType()) seems to match what is done here, but I wonder whether it is always necessary. Is the additional indirection necessary for pointer-sized data types (e.g. intptr_t, or smaller)?
Thanks & PTAL
Turns out this is a duplicate of @vvereschaka's D92142, but @ldionne, I'd still like to land this spelling of it, for consistency with https://github.com/llvm/llvm-project/commit/66e6e37447b183b1c8bac9330a4658530d2d49e6 .
Addressed more comments on the test.
So why not creating a OpenMPIRBuilder::createWorksharingLoop that can be used by clang as well?
Looks like the issue was fixed by 9124fa592098d3794d7b31f83a58e40cc469ff0c.
Is there something I need to do to land this? I'm new to LLVM.
Try again after rebase