[llvm-bugs] [Bug 48425] New: [CloneModule] Cloned module retains some pointers to original module's objects
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Dec 7 02:51:17 PST 2020
https://bugs.llvm.org/show_bug.cgi?id=48425
Bug ID: 48425
Summary: [CloneModule] Cloned module retains some pointers to
original module's objects
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Transformation Utilities
Assignee: unassignedbugs at nondot.org
Reporter: itay.bookstein at nextsilicon.com
CC: llvm-bugs at lists.llvm.org
When BlockAddresses are used as initializers of GlobalVariables,
and the module is cloned, the BlockAddress constants used as
initializers in the cloned module contain pointers to the
BasicBlocks of the old module rather than the new one.
As far as I can tell, in ValueMapper.cpp, Mapper::flush() attempts
to RAUW the temporary basic block it created when attempting to map
the BlockAddress constant which it encountered as the initializer of
a GlobalVariable, and it passes the OldBB when failing to find a
target. To my limited understanding, it sounds risky/incorrect to
fall-back to the OldBB there. The BasicBlocks themselves are of
course properly mapped/cloned into the new module in CloneFunction.cpp,
in function llvm::CloneFunctionInto, but a comment there seems to
talk exactly about it not being legal to clone a function that has
an external BlockAddress referencing it.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201207/bc2f2414/attachment.html>
More information about the llvm-bugs
mailing list