frontend failure when compiling openmp offload with -g

[Quuxplusone]

Bugzilla Link	PR51737
Status	NEW
Importance	P enhancement
Reported by	Ye Luo (xw111luoye@gmail.com)
Reported on	2021-09-03 10:51:49 -0700
Last modified on	2021-09-10 09:21:48 -0700
Version	unspecified
Hardware	PC Linux
CC	huberjn@ornl.gov, jdoerfert@anl.gov, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

got failure when compiling QMCPACK with -g.
No issue on 20210811 but 20210824 already have this issue

1.  <eof> parser at end of file
2.  Code generation
3.  Running pass 'Function Pass Manager' on module
'/home/yeluo/opt/qmcpack/src/QMCWaveFunctions/Fermion/DiracDeterminantBatched.cpp'.
4.  Running pass 'NVPTX Assembly Printer' on function
'@__kmpc_nvptx_parallel_reduce_nowait_v2'
 #0 0x0000000002cf8703 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/soft/compilers/llvm/main-20210903/bin/clang-14+0x2cf8703)
 #1 0x0000000002cf63ee llvm::sys::RunSignalHandlers() (/soft/compilers/llvm/main-20210903/bin/clang-14+0x2cf63ee)
 #2 0x0000000002cf8a8f SignalHandler(int) Signals.cpp:0:0
 #3 0x00007f75e4175f80 __restore_rt (/lib64/libpthread.so.0+0x13f80)
 #4 0x0000000003939e04 llvm::DwarfDebug::emitInitialLocDirective(llvm::MachineFunction const&, unsigned int) (/soft/compilers/llvm/main-20210903/bin/clang-14+0x3939e04)
 #5 0x000000000390c049 llvm::AsmPrinter::emitInitialRawDwarfLocDirective(llvm::MachineFunction const&) (/soft/compilers/llvm/main-20210903/bin/clang-14+0x390c049)
 #6 0x000000000160045c llvm::NVPTXAsmPrinter::emitFunctionEntryLabel() (/soft/compilers/llvm/main-20210903/bin/clang-14+0x160045c)
 #7 0x000000000390eca7 llvm::AsmPrinter::emitFunctionHeader() (/soft/compilers/llvm/main-20210903/bin/clang-14+0x390eca7)
 #8 0x000000000390ff7d llvm::AsmPrinter::emitFunctionBody() (/soft/compilers/llvm/main-20210903/bin/clang-14+0x390ff7d)
 #9 0x0000000001601849 llvm::NVPTXAsmPrinter::runOnMachineFunction(llvm::MachineFunction&) (/soft/compilers/llvm/main-20210903/bin/clang-14+0x1601849)
#10 0x00000000020956ce
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/soft/compilers/llvm/main-20210903/bin/clang-14+0x20956ce)
#11 0x00000000024dbc58 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/soft/compilers/llvm/main-20210903/bin/clang-14+0x24dbc58)
#12 0x00000000024e2408 llvm::FPPassManager::runOnModule(llvm::Module&)
(/soft/compilers/llvm/main-20210903/bin/clang-14+0x24e2408)
#13 0x00000000024dc2f7 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/soft/compilers/llvm/main-20210903/bin/clang-14+0x24dc2f7)
#14 0x0000000002f96564 (anonymous
namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager(clang::BackendAction,
std::unique_ptr<llvm::raw_pwrite_stream,
std::default_delete<llvm::raw_pwrite_stream> >) BackendUtil.cpp:0:0
#15 0x0000000002f8f9ae clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef,
llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream,
std::default_delete<llvm::raw_pwrite_stream> >) (/soft/compilers/llvm/main-
20210903/bin/clang-14+0x2f8f9ae)
#16 0x0000000003caf22f
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/soft/compilers/llvm/main-20210903/bin/clang-14+0x3caf22f)
#17 0x00000000046877c3 clang::ParseAST(clang::Sema&, bool, bool)
(/soft/compilers/llvm/main-20210903/bin/clang-14+0x46877c3)
#18 0x00000000035f9423 clang::FrontendAction::Execute()
(/soft/compilers/llvm/main-20210903/bin/clang-14+0x35f9423)
#19 0x0000000003569648
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/soft/compilers/llvm/main-20210903/bin/clang-14+0x3569648)
#20 0x00000000036b42d2
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/soft/compilers/llvm/main-20210903/bin/clang-14+0x36b42d2)
#21 0x0000000000afb4d2 cc1_main(llvm::ArrayRef<char const*>, char const*,
void*) (/soft/compilers/llvm/main-20210903/bin/clang-14+0xafb4d2)
#22 0x0000000000af93cd ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&)
driver.cpp:0:0
#23 0x0000000000af90bd main (/soft/compilers/llvm/main-20210903/bin/clang-
14+0xaf90bd)
#24 0x00007f75e2c2c34d __libc_start_main (/lib64/libc.so.6+0x2534d)
#25 0x0000000000af623a _start /home/abuild/rpmbuild/BUILD/glibc-
2.31/csu/../sysdeps/x86_64/start.S:122:0
clang-14: error: unable to execute command: Segmentation fault
clang-14: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
0f80961e8c72dd67e1d9a9817b581b9848c9393e)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /soft/compilers/llvm/master-nightly/bin
clang-14: note: diagnostic msg: Error generating preprocessed source(s).

[Quuxplusone]

The first problem, when compiling with `-g`, is that the device runtime bitcode
doesn't have debugging symbols, so when we link it in we seem to get some mixed
debug information. LLVM sees that the module has debug information so it tries
to access it to generate the DWARF debugging symbols, but since not everything
has a valid debug symbol it will eventually get a null pointer and crash.

I tried compiling the runtime library with debugging symbols but that lead to
other problems. It seems that there are call instructions in NVPTX that have no
argument. So when we try to generate debugging symbols we will try to create
symbols for the called function, and  then crash because there is no called
function to access. This is in addition to some other weird errors I've
encountered where it will talk about missing debug information. I created a
simple module that shows the crash in the back-end but I'm not sure what the
root cause is, I have minimal experience with the back-end.
https://godbolt.org/z/M1WfPP78K

[Quuxplusone]

I tried to build bitcode library with debug on and it leads to new issues as
you mentioned. I got crash in
4.  Running pass 'NVPTX Assembly Printer' on function '@__kmpc_target_init'

back to the original issue, do you by change bisect into a commit that breaks
this? I'm wondering if we can just restore the old behavior without fixing all
the debug symbol related issue.

[Quuxplusone]

I think this working on a previous commit is superficial, LLVM expects valid debug information on everything if the module specifies it supports debugging. Ideally the solution would be to maintain two bitcode libraries, one with debugging and one without, and use each accordingly. However, this doesn't work right now as I mentioned previously. So I don't think there's a real solution until that gets fixed.