[flang][debug] Fix issue with argument numbering. #120726
Conversation
Currently fir::isDummyArgument is being used to check if a DeclareOp represents a dummy argument. The argument passed to the function is declOp.getMemref(). This bypasses the code in isDummyArgument that checks for dummy_scope because the `Value` returned by the getMemref() may not have DeclareOp as its defining op. This bypassing mean that sometime a variable will be marked as argument when it should not. This happened in this case where same arg was being used for 2 different result variables with use of `entry` in the function. The solution is to check directly if the declOp has a dummy_scope. If yes, we know this is dummy argument. We can now check if the memref points to the BlockArgument and use its number. This will still miss arguments where memref does not directly point to a BlockArgument but that is missed currently too. Note that we can still evaluate those variable in debugger. It is just that they are not marked as arguments. Fixes llvm#116525.
abidh
requested review from
ergawy,
tblah,
jeanPerier,
dpalermo,
kiranktp and
k-arrows
llvmbot
added
flang
|
@llvm/pr-subscribers-flang-fir-hlfir Author: Abid Qadeer (abidh) ChangesCurrently fir::isDummyArgument is being used to check if a DeclareOp represents a dummy argument. The argument passed to the function is declOp.getMemref(). This bypasses the code in isDummyArgument that checks for dummy_scope because the This bypassing mean that sometime a variable will be marked as argument when it should not. This happened in this case where same arg was being used for 2 different result variables with use of The solution is to check directly if the declOp has a dummy_scope. If yes, we know this is dummy argument. We can now check if the memref points to the BlockArgument and use its number. This will still miss arguments where memref does not directly point to a BlockArgument but that is missed currently too. Note that we can still evaluate those variable in debugger. It is just that they are not marked as arguments. Fixes #116525. Full diff: https://github.com/llvm/llvm-project/pull/120726.diff 2 Files Affected:
diff --git a/flang/lib/Optimizer/Transforms/AddDebugInfo.cpp b/flang/lib/Optimizer/Transforms/AddDebugInfo.cpp
index 3a437c7a0f0137..a8e9d198ccb97c 100644
--- a/flang/lib/Optimizer/Transforms/AddDebugInfo.cpp
+++ b/flang/lib/Optimizer/Transforms/AddDebugInfo.cpp
@@ -121,9 +121,9 @@ void AddDebugInfoPass::handleDeclareOp(fir::cg::XDeclareOp declOp,
// constant attribute of [hl]fir.declare/fircg.ext_declare operation that has
// a dummy_scope operand).
unsigned argNo = 0;
- if (fir::isDummyArgument(declOp.getMemref())) {
- auto arg = llvm::cast<mlir::BlockArgument>(declOp.getMemref());
- argNo = arg.getArgNumber() + 1;
+ if (declOp.getDummyScope()) {
+ if (auto arg = llvm::dyn_cast<mlir::BlockArgument>(declOp.getMemref()))
+ argNo = arg.getArgNumber() + 1;
}
auto tyAttr = typeGen.convertType(fir::unwrapRefType(declOp.getType()),
diff --git a/flang/test/Integration/debug-116525.f90 b/flang/test/Integration/debug-116525.f90
new file mode 100644
index 00000000000000..1916a34df4c12c
--- /dev/null
+++ b/flang/test/Integration/debug-116525.f90
@@ -0,0 +1,12 @@
+! RUN: %flang_fc1 -fopenmp -emit-llvm -debug-info-kind=standalone %s -o -
+
+! Test that this does not cause build failure.
+function s(x)
+ character(len=2) :: x, s, ss
+
+ s = x
+
+ entry ss()
+
+end function s
+
|
Currently fir::isDummyArgument is being used to check if a DeclareOp represents a dummy argument. The argument passed to the function is declOp.getMemref(). This bypasses the code in isDummyArgument that checks for dummy_scope because the
Valuereturned by the getMemref() may not have DeclareOp as its defining op.This bypassing mean that sometime a variable will be marked as argument when it should not. This happened in this case where same arg was being used for 2 different result variables with use of
entryin the function.The solution is to check directly if the declOp has a dummy_scope. If yes, we know this is dummy argument. We can now check if the memref points to the BlockArgument and use its number. This will still miss arguments where memref does not directly point to a BlockArgument but that is missed currently too. Note that we can still evaluate those variable in debugger. It is just that they are not marked as arguments.
Fixes #116525.