[flang] fix unsafe memory access using mlir::ValueRange

[madanial0]

When running the flang/test/HLFIR/simplify-hlfir-intrinsics.fir test case on AIX we encounter issues building op as they are not found in the mlir context:

LLVM ERROR: Building op `arith.subi` but it isn't known in this MLIRContext: the dialect may not be loaded or this operation hasn't been added by the dialect. See also https://mlir.llvm.org/getting_started/Faq/#registered-loaded-dependent-whats-up-with-dialects-management
LLVM ERROR: Building op `hlfir.yield_element` but it isn't known in this MLIRContext: the dialect may not be loaded or this operation hasn't been added by the dialect. See also https://mlir.llvm.org/getting_started/Faq/#registered-loaded-dependent-whats-up-with-dialects-management
LLVM ERROR: Building op `hlfir.yield_element` but it isn't known in this MLIRContext: the dialect may not be loaded or this operation hasn't been added by the dialect. See also https://mlir.llvm.org/getting_started/Faq/#registered-loaded-dependent-whats-up-with-dialects-management

The issue is caused by the "Merge disjoint stack slots" pass and the error is not present if the source is built with -mllvm --no-stack-coloring

Thanks to investigation by @stefanp-ibm we found that "the initializer_list {inputIndices[1], inputIndices[0]} has a lifetime that only exists for the range of the constructor for ValueRange. Once we get to stack coloring we merge the stack slot for that element with another stack slot and then it gets overwritten which corrupts transposedIndices"

The changes below prevents the corruption of transposedIndices and passes the test case.

[llvmbot]

@llvm/pr-subscribers-flang-fir-hlfir

Author: None (madanial0)

Changes

When running the flang/test/HLFIR/simplify-hlfir-intrinsics.fir test case on AIX we encounter issues building op as they are not found in the mlir context:

LLVM ERROR: Building op `arith.subi` but it isn't known in this MLIRContext: the dialect may not be loaded or this operation hasn't been added by the dialect. See also https://mlir.llvm.org/getting_started/Faq/#registered-loaded-dependent-whats-up-with-dialects-management
LLVM ERROR: Building op `hlfir.yield_element` but it isn't known in this MLIRContext: the dialect may not be loaded or this operation hasn't been added by the dialect. See also https://mlir.llvm.org/getting_started/Faq/#registered-loaded-dependent-whats-up-with-dialects-management
LLVM ERROR: Building op `hlfir.yield_element` but it isn't known in this MLIRContext: the dialect may not be loaded or this operation hasn't been added by the dialect. See also https://mlir.llvm.org/getting_started/Faq/#registered-loaded-dependent-whats-up-with-dialects-management

The issue is caused by the "Merge disjoint stack slots" pass and the error is not present if the source is built with -mllvm --no-stack-coloring

Thanks to investigation by @stefanp-ibm we found that "the initializer_list {inputIndices[1], inputIndices[0]} has a lifetime that only exists for the range of the constructor for ValueRange. Once we get to stack coloring we merge the stack slot for that element with another stack slot and then it gets overwritten which corrupts transposedIndices"

The changes below prevents the corruption of transposedIndices and passes the test case.

---

Full diff: https://github.com/llvm/llvm-project/pull/78435.diff

2 Files Affected:

• (modified) flang/lib/Optimizer/HLFIR/Transforms/SimplifyHLFIRIntrinsics.cpp (+2-1)
• (modified) flang/test/HLFIR/simplify-hlfir-intrinsics.fir (-3)

diff --git a/flang/lib/Optimizer/HLFIR/Transforms/SimplifyHLFIRIntrinsics.cpp b/flang/lib/Optimizer/HLFIR/Transforms/SimplifyHLFIRIntrinsics.cpp
index 5f065056bac00c..c15ea737366c71 100644
--- a/flang/lib/Optimizer/HLFIR/Transforms/SimplifyHLFIRIntrinsics.cpp
+++ b/flang/lib/Optimizer/HLFIR/Transforms/SimplifyHLFIRIntrinsics.cpp
@@ -50,7 +50,8 @@ class TransposeAsElementalConversion
     auto genKernel = [&array](mlir::Location loc, fir::FirOpBuilder &builder,
                               mlir::ValueRange inputIndices) -> hlfir::Entity {
       assert(inputIndices.size() == 2 && "checked in TransposeOp::validate");
-      mlir::ValueRange transposedIndices{{inputIndices[1], inputIndices[0]}};
+      const std::initializer_list<mlir::Value> initList = {inputIndices[1], inputIndices[0]};
+      mlir::ValueRange transposedIndices(initList);
       hlfir::Entity element =
           hlfir::getElementAt(loc, builder, array, transposedIndices);
       hlfir::Entity val = hlfir::loadTrivialScalar(loc, builder, element);
diff --git a/flang/test/HLFIR/simplify-hlfir-intrinsics.fir b/flang/test/HLFIR/simplify-hlfir-intrinsics.fir
index b63ddf17515281..aeea8bfc973266 100644
--- a/flang/test/HLFIR/simplify-hlfir-intrinsics.fir
+++ b/flang/test/HLFIR/simplify-hlfir-intrinsics.fir
@@ -1,6 +1,3 @@
-// XFail the following test case on AIX due to potential miscompilation
-// TODO: Crash fir-opt on AIX
-// XFAIL: system-aix
 // RUN: fir-opt --simplify-hlfir-intrinsics %s | FileCheck %s
 
 // box with known extents

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[tblah]

LGTM. Nice find.

Please could you change the commit title/message. From what I can tell, stack merging or anything AIX specific are not the issues here (the problem just happens to only currently show up under these conditions). This fixes undefined behavior on all platforms.

As @stefanp-ibm said, mlir::ValueRange does not own the data it allows iteration over. Therefore, once the initializer_list goes out of scope (after the constructor returns), any access to the pointed-to memory (via the ValueRange) is unsafe.

The fix is correct because it extends the lifetime of the initializer_list to last as long as the ValueRange.