Skip to content

[flang][debug] Unexpected Assertion `!attr.getIsRecSelf() && "unbound DI recursive self reference"' failure #128606

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
akuhlens opened this issue Feb 25, 2025 · 7 comments · Fixed by #129588
Assignees
Labels
crash Prefer [crash-on-valid] or [crash-on-invalid] debuginfo flang:ir

Comments

@akuhlens
Copy link
Contributor

akuhlens commented Feb 25, 2025

This seems to be another case of #122024. The example code is a lot more complicated and I wasn't able to reduce it to a single file. I can delete a fair amount of code, but but couldn't get it down to a single file without the assertion disappearing. It is interesting to note that deleting the switch case for type(TestCase) allows this file to compile and then gets stuck on the next file with the same error.

$ git clone git@github.com:Goddard-Fortran-Ecosystem/pFUnit.git
$ cd pFUnit
$ mkdir build
$ cd build
$ flang --version
flang version 21.0.0git (https://github.com/llvm/llvm-project f6a30021249c3b6aac20f108559915e74943540f)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir:
Build config: +assertions
$ export FC=flang
$ cmake -DCMAKE_INSTALL_PREFIX=../install -DENABLE_TESTS=ON -DSKIP_MPI=YES ..
$ make test
...
[ 14%] Building Fortran object src/funit/core/CMakeFiles/funit-core.dir/TestSuite.F90.o
flang-21: warning: OpenMP support in flang is still experimental [-Wexperimental-option]
flang: /proj/build/llvm/Linux_x86_64/mlir/lib/Target/LLVMIR/DebugTranslation.cpp:276: llvm::DINode* mlir::LLVM::detail::DebugTranslation::translateRecursive(mlir::LLVM::DIRecursiveTypeAttrInterface): Assertion `!attr.getIsRecSelf() && "unbound DI recursive self reference"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang -fc1 -triple x86_64-unknown-linux-gnu -emit-obj -D Robust -I /home/akuhlenschmi/tmp/pFUnit/build/src/funit/mod -I /home/akuhlenschmi/tmp/pFUnit/include -I /home/akuhlenschmi/tmp/pFUnit/build/src/funit/core -I /local/home/akuhlenschmi/tmp/install/GFTL-1.15/include/v2 -I /local/home/akuhlenschmi/tmp/install/GFTL_SHARED-1.10/include/v2 -I /local/home/akuhlenschmi/tmp/install/FARGPARSE-1.9/include -cpp -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu x86-64 -module-dir ../mod -debug-info-kind=standalone -fopenmp -resource-dir /proj/nv/llvm/Linux_x86_64/llvm-4477/lib/clang/21 -mframe-pointer=all -O0 -o CMakeFiles/funit-core.dir/TestSuite.F90.o -x f95-cpp-input /home/akuhlenschmi/tmp/pFUnit/src/funit/core/TestSuite.F90
 #0 0x0000556097d9d13b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x450713b)
 #1 0x0000556097d9a954 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
 #2 0x00007ff69983e520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #3 0x00007ff6998929fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #4 0x00007ff6998929fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10
 #5 0x00007ff6998929fc pthread_kill ./nptl/pthread_kill.c:89:10
 #6 0x00007ff69983e476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #7 0x00007ff6998247f3 abort ./stdlib/abort.c:81:7
 #8 0x00007ff69982471b _nl_load_domain ./intl/loadmsgcat.c:1177:9
 #9 0x00007ff699835e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#10 0x000055609bb56359 mlir::LLVM::detail::DebugTranslation::translateRecursive(mlir::LLVM::DIRecursiveTypeAttrInterface) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c0359)
#11 0x000055609bb565ed mlir::LLVM::detail::DebugTranslation::translate(mlir::LLVM::DINodeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c05ed)
#12 0x000055609bb579c4 mlir::LLVM::detail::DebugTranslation::translateImpl(mlir::LLVM::DIDerivedTypeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c19c4)
#13 0x000055609bb569bb mlir::LLVM::detail::DebugTranslation::translate(mlir::LLVM::DINodeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c09bb)
#14 0x000055609bb579c4 mlir::LLVM::detail::DebugTranslation::translateImpl(mlir::LLVM::DIDerivedTypeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c19c4)
#15 0x000055609bb569bb mlir::LLVM::detail::DebugTranslation::translate(mlir::LLVM::DINodeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c09bb)
#16 0x000055609bb58b70 mlir::LLVM::detail::DebugTranslation::getMDTupleOrNull(llvm::ArrayRef<mlir::LLVM::DINodeAttr>) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c2b70)
#17 0x000055609bb5995b mlir::LLVM::detail::DebugTranslation::translateImpl(mlir::LLVM::DICompositeTypeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c395b)
@llvmbot llvmbot added the flang Flang issues not falling into any other category label Feb 25, 2025
@EugeneZelenko EugeneZelenko added debuginfo flang:ir crash Prefer [crash-on-valid] or [crash-on-invalid] and removed flang Flang issues not falling into any other category labels Feb 25, 2025
@llvmbot
Copy link
Member

llvmbot commented Feb 25, 2025

@llvm/issue-subscribers-flang-ir

Author: Andre Kuhlenschmidt (akuhlens)

This seems to be another case of #122024. The example code is a lot more complicated and I wasn't able to reduce it to a single file. I can delete a fair amount of code, but but couldn't get it down to a single file without the assertion disappearing. It is interesting to note that deleting the [switch case for `type(TestCase)`](https://github.com/Goddard-Fortran-Ecosystem/pFUnit/blob/cbe21b95eff70804acfd7f5a9b68dec291781c4a/src/funit/core/TestSuite.F90#L164) allows this file to compile and then gets stuck on the next file with the same error.
$ git clone git@<!-- -->github.com:Goddard-Fortran-Ecosystem/pFUnit.git
$ cd pFUnit
$ mkdir build
$ cd build
$ flang --version
flang version 21.0.0git (https://github.com/llvm/llvm-project f6a30021249c3b6aac20f108559915e74943540f)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir:
Build config: +assertions
$ export FC=flang
$ cmake -DCMAKE_INSTALL_PREFIX=../install -DENABLE_TESTS=ON -DSKIP_MPI=YES ..
$ make test
...
[ 14%] Building Fortran object src/funit/core/CMakeFiles/funit-core.dir/TestSuite.F90.o
flang-21: warning: OpenMP support in flang is still experimental [-Wexperimental-option]
flang: /proj/build/llvm/Linux_x86_64/mlir/lib/Target/LLVMIR/DebugTranslation.cpp:276: llvm::DINode* mlir::LLVM::detail::DebugTranslation::translateRecursive(mlir::LLVM::DIRecursiveTypeAttrInterface): Assertion `!attr.getIsRecSelf() &amp;&amp; "unbound DI recursive self reference"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang -fc1 -triple x86_64-unknown-linux-gnu -emit-obj -D Robust -I /home/akuhlenschmi/tmp/pFUnit/build/src/funit/mod -I /home/akuhlenschmi/tmp/pFUnit/include -I /home/akuhlenschmi/tmp/pFUnit/build/src/funit/core -I /local/home/akuhlenschmi/tmp/install/GFTL-1.15/include/v2 -I /local/home/akuhlenschmi/tmp/install/GFTL_SHARED-1.10/include/v2 -I /local/home/akuhlenschmi/tmp/install/FARGPARSE-1.9/include -cpp -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu x86-64 -module-dir ../mod -debug-info-kind=standalone -fopenmp -resource-dir /proj/nv/llvm/Linux_x86_64/llvm-4477/lib/clang/21 -mframe-pointer=all -O0 -o CMakeFiles/funit-core.dir/TestSuite.F90.o -x f95-cpp-input /home/akuhlenschmi/tmp/pFUnit/src/funit/core/TestSuite.F90
 #<!-- -->0 0x0000556097d9d13b llvm::sys::PrintStackTrace(llvm::raw_ostream&amp;, int) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x450713b)
 #<!-- -->1 0x0000556097d9a954 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
 #<!-- -->2 0x00007ff69983e520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #<!-- -->3 0x00007ff6998929fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #<!-- -->4 0x00007ff6998929fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10
 #<!-- -->5 0x00007ff6998929fc pthread_kill ./nptl/pthread_kill.c:89:10
 #<!-- -->6 0x00007ff69983e476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #<!-- -->7 0x00007ff6998247f3 abort ./stdlib/abort.c:81:7
 #<!-- -->8 0x00007ff69982471b _nl_load_domain ./intl/loadmsgcat.c:1177:9
 #<!-- -->9 0x00007ff699835e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#<!-- -->10 0x000055609bb56359 mlir::LLVM::detail::DebugTranslation::translateRecursive(mlir::LLVM::DIRecursiveTypeAttrInterface) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c0359)
#<!-- -->11 0x000055609bb565ed mlir::LLVM::detail::DebugTranslation::translate(mlir::LLVM::DINodeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c05ed)
#<!-- -->12 0x000055609bb579c4 mlir::LLVM::detail::DebugTranslation::translateImpl(mlir::LLVM::DIDerivedTypeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c19c4)
#<!-- -->13 0x000055609bb569bb mlir::LLVM::detail::DebugTranslation::translate(mlir::LLVM::DINodeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c09bb)
#<!-- -->14 0x000055609bb579c4 mlir::LLVM::detail::DebugTranslation::translateImpl(mlir::LLVM::DIDerivedTypeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c19c4)
#<!-- -->15 0x000055609bb569bb mlir::LLVM::detail::DebugTranslation::translate(mlir::LLVM::DINodeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c09bb)
#<!-- -->16 0x000055609bb58b70 mlir::LLVM::detail::DebugTranslation::getMDTupleOrNull(llvm::ArrayRef&lt;mlir::LLVM::DINodeAttr&gt;) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c2b70)
#<!-- -->17 0x000055609bb5995b mlir::LLVM::detail::DebugTranslation::translateImpl(mlir::LLVM::DICompositeTypeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c395b)

@llvmbot
Copy link
Member

llvmbot commented Feb 25, 2025

@llvm/issue-subscribers-debuginfo

Author: Andre Kuhlenschmidt (akuhlens)

This seems to be another case of #122024. The example code is a lot more complicated and I wasn't able to reduce it to a single file. I can delete a fair amount of code, but but couldn't get it down to a single file without the assertion disappearing. It is interesting to note that deleting the [switch case for `type(TestCase)`](https://github.com/Goddard-Fortran-Ecosystem/pFUnit/blob/cbe21b95eff70804acfd7f5a9b68dec291781c4a/src/funit/core/TestSuite.F90#L164) allows this file to compile and then gets stuck on the next file with the same error.
$ git clone git@<!-- -->github.com:Goddard-Fortran-Ecosystem/pFUnit.git
$ cd pFUnit
$ mkdir build
$ cd build
$ flang --version
flang version 21.0.0git (https://github.com/llvm/llvm-project f6a30021249c3b6aac20f108559915e74943540f)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir:
Build config: +assertions
$ export FC=flang
$ cmake -DCMAKE_INSTALL_PREFIX=../install -DENABLE_TESTS=ON -DSKIP_MPI=YES ..
$ make test
...
[ 14%] Building Fortran object src/funit/core/CMakeFiles/funit-core.dir/TestSuite.F90.o
flang-21: warning: OpenMP support in flang is still experimental [-Wexperimental-option]
flang: /proj/build/llvm/Linux_x86_64/mlir/lib/Target/LLVMIR/DebugTranslation.cpp:276: llvm::DINode* mlir::LLVM::detail::DebugTranslation::translateRecursive(mlir::LLVM::DIRecursiveTypeAttrInterface): Assertion `!attr.getIsRecSelf() &amp;&amp; "unbound DI recursive self reference"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang -fc1 -triple x86_64-unknown-linux-gnu -emit-obj -D Robust -I /home/akuhlenschmi/tmp/pFUnit/build/src/funit/mod -I /home/akuhlenschmi/tmp/pFUnit/include -I /home/akuhlenschmi/tmp/pFUnit/build/src/funit/core -I /local/home/akuhlenschmi/tmp/install/GFTL-1.15/include/v2 -I /local/home/akuhlenschmi/tmp/install/GFTL_SHARED-1.10/include/v2 -I /local/home/akuhlenschmi/tmp/install/FARGPARSE-1.9/include -cpp -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu x86-64 -module-dir ../mod -debug-info-kind=standalone -fopenmp -resource-dir /proj/nv/llvm/Linux_x86_64/llvm-4477/lib/clang/21 -mframe-pointer=all -O0 -o CMakeFiles/funit-core.dir/TestSuite.F90.o -x f95-cpp-input /home/akuhlenschmi/tmp/pFUnit/src/funit/core/TestSuite.F90
 #<!-- -->0 0x0000556097d9d13b llvm::sys::PrintStackTrace(llvm::raw_ostream&amp;, int) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x450713b)
 #<!-- -->1 0x0000556097d9a954 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
 #<!-- -->2 0x00007ff69983e520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #<!-- -->3 0x00007ff6998929fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #<!-- -->4 0x00007ff6998929fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10
 #<!-- -->5 0x00007ff6998929fc pthread_kill ./nptl/pthread_kill.c:89:10
 #<!-- -->6 0x00007ff69983e476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #<!-- -->7 0x00007ff6998247f3 abort ./stdlib/abort.c:81:7
 #<!-- -->8 0x00007ff69982471b _nl_load_domain ./intl/loadmsgcat.c:1177:9
 #<!-- -->9 0x00007ff699835e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#<!-- -->10 0x000055609bb56359 mlir::LLVM::detail::DebugTranslation::translateRecursive(mlir::LLVM::DIRecursiveTypeAttrInterface) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c0359)
#<!-- -->11 0x000055609bb565ed mlir::LLVM::detail::DebugTranslation::translate(mlir::LLVM::DINodeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c05ed)
#<!-- -->12 0x000055609bb579c4 mlir::LLVM::detail::DebugTranslation::translateImpl(mlir::LLVM::DIDerivedTypeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c19c4)
#<!-- -->13 0x000055609bb569bb mlir::LLVM::detail::DebugTranslation::translate(mlir::LLVM::DINodeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c09bb)
#<!-- -->14 0x000055609bb579c4 mlir::LLVM::detail::DebugTranslation::translateImpl(mlir::LLVM::DIDerivedTypeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c19c4)
#<!-- -->15 0x000055609bb569bb mlir::LLVM::detail::DebugTranslation::translate(mlir::LLVM::DINodeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c09bb)
#<!-- -->16 0x000055609bb58b70 mlir::LLVM::detail::DebugTranslation::getMDTupleOrNull(llvm::ArrayRef&lt;mlir::LLVM::DINodeAttr&gt;) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c2b70)
#<!-- -->17 0x000055609bb5995b mlir::LLVM::detail::DebugTranslation::translateImpl(mlir::LLVM::DICompositeTypeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c395b)

@abidh
Copy link
Contributor

abidh commented Feb 26, 2025

Thanks for reporting the issue. I will have a look.

@akuhlens
Copy link
Contributor Author

A further update: reverting bfd3e25 "fixes" this, though that hardly seems like the long term solution, but hopefully that gives you a little more evidence for debugging. Making any progress here?

@abidh
Copy link
Contributor

abidh commented Feb 28, 2025

A further update: reverting bfd3e25 "fixes" this, though that hardly seems like the long term solution, but hopefully that gives you a little more evidence for debugging. Making any progress here?

Thanks for this hint. The commit you mentioned was done to enable the variable debugging for things like OpenMP target region where DeclareOp is not in the entry block. I have not been able to investigate it yet but hoping to get to it next week.

@abidh
Copy link
Contributor

abidh commented Mar 3, 2025

Can you kindly try this one liner patch and report if this fixes your issue.

diff --git a/flang/lib/Optimizer/Dialect/FIRType.cpp b/flang/lib/Optimizer/Dialect/FIRType.cpp
index 719cb1b9d75a..b78d5abd544d 100644
--- a/flang/lib/Optimizer/Dialect/FIRType.cpp
+++ b/flang/lib/Optimizer/Dialect/FIRType.cpp
@@ -210,7 +210,7 @@ mlir::Type getDerivedType(mlir::Type ty) {
           return seq.getEleTy();
         return p.getEleTy();
       })
-      .Case<fir::BoxType>([](auto p) { return getDerivedType(p.getEleTy()); })
+      .Case<fir::BaseBoxType>([](auto p) { return getDerivedType(p.getEleTy()); })
       .Default([](mlir::Type t) { return t; });
 }

abidh added a commit to abidh/llvm-project that referenced this issue Mar 3, 2025
While checking if a type should be cached or not, we use
getDerivedType to peel outer layers to get to the base type. This
function did not peel the `fir.class` which caused the algorithm to
fail.

Fixes llvm#128606.
abidh added a commit that referenced this issue Mar 4, 2025
…#129588)

While checking if a type should be cached or not, we use
`getDerivedType` to peel outer layers and get to the base type. This
function did not peel the `fir.class` which caused the algorithm to
fail.

Fixes #128606.
@akuhlens
Copy link
Contributor Author

akuhlens commented Mar 5, 2025

Thank you! This is now working in our test suite.

jph-13 pushed a commit to jph-13/llvm-project that referenced this issue Mar 21, 2025
…llvm#129588)

While checking if a type should be cached or not, we use
`getDerivedType` to peel outer layers and get to the base type. This
function did not peel the `fir.class` which caused the algorithm to
fail.

Fixes llvm#128606.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crash Prefer [crash-on-valid] or [crash-on-invalid] debuginfo flang:ir
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants