Compiler crashes when try to access a member variable of a class through inline assembly about llvm-mos

[johnwbyrd]

Interestingly, codegen is happy when you coerce the array to a local variable:

https://godbolt.org/z/rjePzW9KW

[johnwbyrd]

A possibly more useful stack dump:

fatal error: error in backend: unable to translate instruction: call (in function: main)
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: /opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang++ -gdwarf-4 -g -o /app/output.s -S -fno-lto -mllvm -zp-avail=224 -fcolor-diagnostics -fno-crash-diagnostics -Os <source>
1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module '<source>'.
4.	Running pass 'IRTranslator' on function '@main'
 #0 0x000057c33ba706bb llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x15396bb)
 #1 0x000057c33ba6eeed llvm::sys::RunSignalHandlers() (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x1537eed)
 #2 0x000057c33ba1f657 (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x14e8657)
 #3 0x000057c33ba1f927 (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x14e8927)
 #4 0x000057c33ba6bc07 llvm::sys::Process::Exit(int, bool) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x1534c07)
 #5 0x000057c33b33f117 (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0xe08117)
 #6 0x000057c33ba2267f llvm::report_fatal_error(llvm::Twine const&, bool) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x14eb67f)
 #7 0x000057c33c1d1f03 (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x1c9af03)
 #8 0x000057c33c1e32e8 llvm::IRTranslator::runOnMachineFunction(llvm::MachineFunction&) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x1cac2e8)
 #9 0x000057c33b543c6c (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x100cc6c)
#10 0x000057c33b7f15fe llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x12ba5fe)
#11 0x000057c33b7f176b llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x12ba76b)
#12 0x000057c33b7f1e5d llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x12bae5d)
#13 0x000057c33bb7fa45 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>, clang::BackendConsumer*) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x1648a45)
#14 0x000057c33bee2672 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x19ab672)
#15 0x000057c33cce203e clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x27ab03e)
#16 0x000057c33bee2720 clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x19ab720)
#17 0x000057c33c0184cf clang::FrontendAction::Execute() (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x1ae14cf)
#18 0x000057c33bfd85b2 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x1aa15b2)
#19 0x000057c33c085c29 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x1b4ec29)
#20 0x000057c33b340395 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0xe09395)
#21 0x000057c33b33c71f (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0xe0571f)
#22 0x000057c33bf04e2f (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x19cde2f)
#23 0x000057c33ba1f8f0 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x14e88f0)
#24 0x000057c33bf05799 (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x19ce799)
#25 0x000057c33bee6d96 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x19afd96)
#26 0x000057c33bee6eb7 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x19afeb7)
#27 0x000057c33beefbdd clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0x19b8bdd)
#28 0x000057c33b33e64c clang_main(int, char**, llvm::ToolContext const&) (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0xe0764c)
#29 0x000057c33b1a91b1 main (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0xc721b1)
#30 0x000070934c429d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#31 0x000070934c429e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#32 0x000057c33b33be6e _start (/opt/compiler-explorer/llvm-mos-trunk/bin/mos-c64-clang+++0xe04e6e)
mos-c64-clang++: error: clang frontend command failed with exit code 70 (use -v to see invocation)
Compiler returned: 70

[AGPX]

Interestingly, codegen is happy when you coerce the array to a local variable:

https://godbolt.org/z/rjePzW9KW

Yes, but doesn't resolve the problem because I need to write in the member variable. I'm stuck :-( . Any workaround? Is there a way to write this routine with an external assembler?

[johnwbyrd]

The workaround is clearly not a fix. I'm a little confused as to why the workaround works at all. Meanwhile, you may be able to get by, by temporarily by copying a pointer to a member as I have done.

[mysterymath]

I find it helpful when looking at inline asm like this to try to imagine what a human would try to emit if they were playing the role of the compiler. Here we have a member function, test, which gets handed an implcit this pointer. How could the compiler possible know what number to put in the assembly string for lda? It would have to be some compile-time constant number or symbol that it can use with the absolute addressing mode, but the actual address would be different every time the function were called.

There was probably a reasoanbly good error message for this case generated internally, but we still haven't been able to surface it. I looked and we didn't have a good issue filed for that, so I made one to track it: #463

As far as this goes, it's probably WAI. If you to indirect through a runtime variable address in inline assembly, you'll need to put it in an imaginary pointer register using e.g. r, then indirect through the pointer using an indirect addressing mode.