================
@@ -141,6 +143,110 @@ createMapInfoOp(fir::FirOpBuilder &builder, 
mlir::Location loc,
   return op;
 }
 
+omp::ObjectList gatherObjects(omp::Object obj,
+                              semantics::SemanticsContext &semaCtx) {
+  omp::ObjectList objList;
+  std::optional<omp::Object> baseObj = getBaseObject(obj, semaCtx);
+  while (baseObj.has_value()) {
+    objList.push_back(baseObj.value());
+    baseObj = getBaseObject(baseObj.value(), semaCtx);
+  }
+  return omp::ObjectList{llvm::reverse(objList)};
+}
+
+bool duplicateMemberMapInfo(OmpMapMemberIndicesData &parentMembers,
+                            llvm::SmallVectorImpl<int> &memberIndices) {
+  // A variation of std:equal that supports non-equal length index lists for 
our
+  // specific use-case, if one is larger than the other, we use -1, the default
+  // filler element in place of the smaller vector, this prevents UB from over
+  // indexing and removes the need for us to do any filling of intermediate
+  // index lists we'll discard.
+  auto isEqual = [](auto first1, auto last1, auto first2, auto last2) {
+    int v1, v2;
+    for (; first1 != last1; ++first1, ++first2) {
----------------
agozillon wrote:

it's a slightly modified copy of the std::equal implementation. extended to 
substitute -1 (the filler element indicating a non-index value) in cases where 
we over index the ranges (but as you've stated the scenario for the 
first1/last1 range is impossible, thank you for that, you can tell I was 
pulling my hair out trying to find the UB I'd made in the original 
implementation :-)).

However, I think you're correct in that it would not work perfectly in these 
scenarios, I believe in most scenarios the pre-condition is met (hence not 
having issues with it before hand), but this isn't a guarantee and I don't 
believe the behavior of std::equal would reflect equality appropriately in 
these cases, so I'll adjust it to select the larger length range as the index 
or just use the largest std::distance. 

Thank you very much for the catch! :D 


https://github.com/llvm/llvm-project/pull/96266
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

Reply via email to