[Flang][OpenMP] Crash with `map(structure-component)`

[kparzysz]

Having a map clause with a structure component leads to a crash.

subroutine foo()
  implicit none

  type t0
    integer :: a0
  end type

  type(t0) :: a

  !$omp target map(a%a0)
  a%a0 = 0
  !$omp end target
end

bbc -o - sep1.f90 -fopenmp

PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /work/kparzysz/c/org/bin/bbc -o - sep1.f90 -fopenmp
 #0 0x00007f71a25c81b0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/work/kparzysz/c/org/bin/../lib/libLLVMSupport.so.19git+0x1c81b0)
 #1 0x00007f71a25c55bf llvm::sys::RunSignalHandlers() (/work/kparzysz/c/org/bin/../lib/libLLVMSupport.so.19git+0x1c55bf)
 #2 0x00007f71a25c5715 SignalHandler(int) Signals.cpp:0:0
 #3 0x00007f71a1c42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #4 0x00007f71a78005e6 Fortran::lower::SymMap::lookupSymbol(Fortran::common::Reference<Fortran::semantics::Symbol const>) (/work/kparzysz/c/org/bin/../lib/libFortranLower.so.19git+0x6005e6)
 #5 0x00007f71a73a1216 (anonymous namespace)::FirConverter::lookupSymbol(Fortran::semantics::Symbol const&, Fortran::lower::SymMap*) Bridge.cpp:0:0
 #6 0x00007f71a73a1c10 (anonymous namespace)::FirConverter::getSymbolExtendedValue(Fortran::semantics::Symbol const&, Fortran::lower::SymMap*) Bridge.cpp:0:0
 #7 0x00007f71a7796be9 genTargetOp(Fortran::lower::AbstractConverter&, Fortran::lower::pft::Evaluation&, Fortran::semantics::SemanticsContext&, bool, mlir::Location, Fortran::parser::OmpClauseList const&, llvm::omp::Directive, bool) (.constprop.0) OpenMP.cpp:0:0
[...]

[kparzysz]

First of all, getOmpObjectSymbol doesn't get the case when the designator is a StructureComponent. We simply put the return value (nullptr in this case) in the mapSymbols list, which crashes shortly after. This can be fixed easily by returning the symbol associated with the component name, but problems continue.
That change leads to another crash:

error: loc("/work/kparzysz/test/sep1.f90":1:1): symbol is not mapped to any IR value
LLVM ERROR: aborting
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /work/kparzysz/git/llvm.org/b/x86/bin/bbc -o - sep1.f90 -fopenmp
 #0 0x00007f8b801c81b0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/work/kparzysz/git/llvm.org/b/x86/bin/../lib/libLLVMSupport.so.19git+0x1c81b0)
 #1 0x00007f8b801c55bf llvm::sys::RunSignalHandlers() (/work/kparzysz/git/llvm.org/b/x86/bin/../lib/libLLVMSupport.so.19git+0x1c55bf)
 #2 0x00007f8b801c5715 SignalHandler(int) Signals.cpp:0:0
 #3 0x00007f8b7f842520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #4 0x00007f8b7f8969fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #5 0x00007f8b7f8969fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10
 #6 0x00007f8b7f8969fc pthread_kill ./nptl/pthread_kill.c:89:10
 #7 0x00007f8b7f842476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #8 0x00007f8b7f8287f3 abort ./stdlib/abort.c:81:7
 #9 0x00007f8b80054fb4 llvm::GlobPattern::create(llvm::StringRef, std::optional<unsigned long>) (.cold) GlobPattern.cpp:0:0
#10 0x00007f8b800e1e5e (/work/kparzysz/git/llvm.org/b/x86/bin/../lib/libLLVMSupport.so.19git+0xe1e5e)
#11 0x00007f8b84f4dd31 fir::emitFatalError(mlir::Location, llvm::Twine const&, bool) (/work/kparzysz/git/llvm.org/b/x86/bin/../lib/libFortranLower.so.19git+0x14dd31)
#12 0x00007f8b84fa56d0 (anonymous namespace)::FirConverter::getSymbolExtendedValue(Fortran::semantics::Symbol const&, Fortran::lower::SymMap*) Bridge.cpp:0:0
#13 0x00007f8b8539f138 genTargetOp(Fortran::lower::AbstractConverter&, Fortran::lower::pft::Evaluation&, Fortran::semantics::SemanticsContext&, bool, mlir::Location, Fortran::parser::OmpClauseList const&, llvm::omp::Directive, bool) (.constprop.0) OpenMP.cpp:0:0
[...]

Evidently, at some point the symbol (created during semantic analysis) needs to be bound to something, but it's not clear at which point the value needs to be created. In the original design, the bridge's symbol table wasn't exposed to the OpenMP lowering, which suggests that the bridge was meant to create the value. The symbol table is available now in OpenMP, so the code dealing with the map clause could do it.

@kiranchandramohan Do you have any suggestions on what to do here?

[kiranchandramohan]

In the original design, the bridge's symbol table wasn't exposed to the OpenMP lowering, which suggests that the bridge was meant to create the value.

The AbstractConverter has a converter.bindSymbol function that can be used to set the mlir value/fir extended value binding of the symbol. You can check where the binding is created for the non-structure component symbols and do something similar here.

[kparzysz]

It seems like component symbols aren't meant to be instantiated---they are specifically ignored in instantiateVariable.

When an object is mapped, its address becomes an argument to the omp.target op, and has a corresponding parameter in the op's entry block. The crash happens when when we try to bind symbols (corresponding to the mapped objects) to the block parameters. These symbols are bound to "extended values", whereas the parameters are not extended values. When we try to recreate the extended values, we look up the symbols' existing bindings (via getSymbolExtendedValue).

When getOmpObjectSymbol returns nullptr for a component, the nullptr ends up on the list of mapped symbols. In the process of looking up the symbol, the nullptr gets dereferenced causing a crash.

The simplest fix would simply be to skip null symbols when creating extended values (we should still keep them on the list of mapped symbols, because that list has to correspond to the list of block parameters). The problem is that a null symbol may be a result of some unrelated error. Instead, the actual fix is to put the component symbol on the list, and then recognize them (and skip them) when creating extended values.

[llvmbot]

@llvm/issue-subscribers-flang-ir

Author: Krzysztof Parzyszek (kparzysz)

Having a `map` clause with a structure component leads to a crash.

subroutine foo()
  implicit none

  type t0
    integer :: a0
  end type

  type(t0) :: a

  !$omp target map(a%a0)
  a%a0 = 0
  !$omp end target
end

bbc -o - sep1.f90 -fopenmp

PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /work/kparzysz/c/org/bin/bbc -o - sep1.f90 -fopenmp
 #<!-- -->0 0x00007f71a25c81b0 llvm::sys::PrintStackTrace(llvm::raw_ostream&amp;, int) (/work/kparzysz/c/org/bin/../lib/libLLVMSupport.so.19git+0x1c81b0)
 #<!-- -->1 0x00007f71a25c55bf llvm::sys::RunSignalHandlers() (/work/kparzysz/c/org/bin/../lib/libLLVMSupport.so.19git+0x1c55bf)
 #<!-- -->2 0x00007f71a25c5715 SignalHandler(int) Signals.cpp:0:0
 #<!-- -->3 0x00007f71a1c42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #<!-- -->4 0x00007f71a78005e6 Fortran::lower::SymMap::lookupSymbol(Fortran::common::Reference&lt;Fortran::semantics::Symbol const&gt;) (/work/kparzysz/c/org/bin/../lib/libFortranLower.so.19git+0x6005e6)
 #<!-- -->5 0x00007f71a73a1216 (anonymous namespace)::FirConverter::lookupSymbol(Fortran::semantics::Symbol const&amp;, Fortran::lower::SymMap*) Bridge.cpp:0:0
 #<!-- -->6 0x00007f71a73a1c10 (anonymous namespace)::FirConverter::getSymbolExtendedValue(Fortran::semantics::Symbol const&amp;, Fortran::lower::SymMap*) Bridge.cpp:0:0
 #<!-- -->7 0x00007f71a7796be9 genTargetOp(Fortran::lower::AbstractConverter&amp;, Fortran::lower::pft::Evaluation&amp;, Fortran::semantics::SemanticsContext&amp;, bool, mlir::Location, Fortran::parser::OmpClauseList const&amp;, llvm::omp::Directive, bool) (.constprop.0) OpenMP.cpp:0:0
[...]