[ThinLTO] Fix bot failures by avoiding threaded map modifications

Ensure multiple threads won't have to modify map, probable cause of
bot failures from r270584 such as:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/13095

llvm-svn: 270595

1 files changed, 5 insertions, 3 deletions

diff --git a/llvm/lib/LTO/ThinLTOCodeGenerator.cpp b/llvm/lib/LTO/ThinLTOCodeGenerator.cpp
index bfcff4c9cfe..d746d47a2d7 100644
--- a/llvm/lib/LTO/ThinLTOCodeGenerator.cpp
+++ b/llvm/lib/LTO/ThinLTOCodeGenerator.cpp
@@ -937,10 +937,12 @@ void ThinLTOCodeGenerator::run() {
   // Changes are made in the index, consumed in the ThinLTO backends.
   thinLTOInternalizeAndPromoteInIndex(*Index, isExported);
 
-  // Make sure that every module has an entry in the ExportLists to enable
-  // threaded access to this map below
-  for (auto &DefinedGVSummaries : ModuleToDefinedGVSummaries)
+  // Make sure that every module has an entry in the ExportLists and
+  // ResolvedODR maps to enable threaded access to these maps below.
+  for (auto &DefinedGVSummaries : ModuleToDefinedGVSummaries) {
     ExportLists[DefinedGVSummaries.first()];
+    ResolvedODR[DefinedGVSummaries.first()];
+  }
 
   // Compute the ordering we will process the inputs: the rough heuristic here
   // is to sort them per size so that the largest module get schedule as soon as