Segmentation fault during running llvm-spirv

[davidrohr]

The attached test case segfaults for me while running llvm-spirv (Using current master llvm-spirv and latest clang from git commit c78da41cdae532adb51d10ed73482642881346dd + the fixes from https://bugs.llvm.org/show_bug.cgi?id=43145).
test.tar.gz

Commands to reproduce:

clang++ -cl-std=clc++ -x cl -emit-llvm --target=spir64-unknown-unknown -cl-denorms-are-zero -cl-mad-enable -cl-no-signed-zeros -ferror-limit=1000 -Xclang -finclude-default-header -Dcl_clang_storage_class_specifiers -Wno-invalid-constexpr -c test.cl -o test.bc
llvm-spirv test.bc

I am getting the following segfault:

Stack dump:
0.      Program arguments: llvm-spirv test.bc 
1.      Running pass 'LLVMToSPIRV' on module 'test.bc'.
 #0 0x00007f1a027c995a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/llvm/10/lib64/libLLVM-10svn.so+0xa3e95a)
 #1 0x00007f1a027c7924 llvm::sys::RunSignalHandlers() (/usr/lib/llvm/10/lib64/libLLVM-10svn.so+0xa3c924)
 #2 0x00007f1a027c7aa5 (/usr/lib/llvm/10/lib64/libLLVM-10svn.so+0xa3caa5)
 #3 0x00007f1a018f10d0 (/lib64/libc.so.6+0x390d0)
 #4 0x000055cfd6eb9c86 SPIRV::SPIRVModuleImpl::addUnaryInst(spv::Op, SPIRV::SPIRVType*, SPIRV::SPIRVValue*, SPIRV::SPIRVBasicBlock*) (/usr/bin/llvm-spirv+0x23bc86)
 #5 0x000055cfd6e54446 SPIRV::LLVMToSPIRV::transValueWithoutDecoration(llvm::Value*, SPIRV::SPIRVBasicBlock*, bool) (/usr/bin/llvm-spirv+0x1d6446)
 #6 0x000055cfd6e5533d (/usr/bin/llvm-spirv+0x1d733d)
 #7 0x000055cfd6e5ce4f SPIRV::LLVMToSPIRV::transFunction(llvm::Function*) (/usr/bin/llvm-spirv+0x1dee4f)
 #8 0x000055cfd6e5d73c SPIRV::LLVMToSPIRV::translate() (/usr/bin/llvm-spirv+0x1df73c)
 #9 0x000055cfd6e5d8f3 SPIRV::LLVMToSPIRV::runOnModule(llvm::Module&) (/usr/bin/llvm-spirv+0x1df8f3)
#10 0x00007f1a028d06fe llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/lib/llvm/10/lib64/libLLVM-10svn.so+0xb456fe)
#11 0x000055cfd6e5da16 llvm::writeSpirv(llvm::Module*, SPIRV::TranslatorOpts const&, std::ostream&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (/usr/bin/llvm-spirv+0x1dfa16)
#12 0x000055cfd6dc80de main (/usr/bin/llvm-spirv+0x14a0de)
#13 0x00007f1a018dbe5b __libc_start_main (/lib64/libc.so.6+0x23e5b)
#14 0x000055cfd6dcc1ca _start (/usr/bin/llvm-spirv+0x14e1ca)
Segmentation fault

@svenvh @AnastasiaStulova : This is the follow-up bug report to https://bugs.llvm.org/show_bug.cgi?id=43145. This currently blocks my test with SPIR-V.

[svenvh]

The problem seems to be that some memcpy calls have been rewritten into memset calls with a non-zero value argument, whereas the translator currently only handles memset calls with 0.

I'll have a look at extending the translator to handle this case. In the mean time, you could try generating the .bc file by passing -O0 to Clang.

[davidrohr]

@svenvh : I tried again to run the llvm-spirv converter (latest master of llvm/clang + master of the converter). It still segfaults, but the backtrace is now different. I am not sure if this is still the same error.

I am attaching the latest precompiled OpenCL code.
test.cl.tar.gz

I am getting the same error also when I pass the -O0 flag

[svenvh]

@svenvh : I tried again to run the llvm-spirv converter (latest master of llvm/clang + master of the converter). It still segfaults, but the backtrace is now different. I am not sure if this is still the same error.

I am attaching the latest precompiled OpenCL code.
test.cl.tar.gz

I am getting the same error also when I pass the -O0 flag

Yes, this backtrace is different indeed. The problem in this case seems to be the use of unsigned long long, which is a reserved data type in OpenCL. Besides that, it cannot be represented as an OpTypeInt according to the OpenCL SPIR-V Environment Specification (which only allows 8, 16, 32, or 64 bit widths).

[davidrohr]

@svenvh : Indeed, the problem seems to be the long long data type.
I fixed it for now by using size_t instead. But I am wondering what is the problem actually. Long long is 64 bit on all architectures I know, so why is it not working for OpenCL?
In any case, a reasonable error message would be helpful.

[davidrohr]

@svenvh : Coming back to the original bug: Indeed, the problem goes away with -O0, but in the long run this is not what I want. Any estimate when this might be fixed? In general, memset with non-zero argument seems legit, so why isn't the translator handling it?

[AlexeySachkov]

@davidrohr,

Long long is 64 bit on all architectures I know, so why is it not working for OpenCL?

See section 6.1.4 Reserved Data Types of OpenCL C spec (both 1.2 and 2.0): long long is reserved data type which cannot be used by applications (also, it corresponds to a 128-bit integer)

[StuartDBrady]

@davidrohr, in OpenCL C, long always has a width of 64 bits.

[davidrohr]

Thx, as I said, I fixed it in my code. But if the data type is reserved, I would prefer a proper error message (from either clang or the converter) instead of a stack trace.
Anyhow, that part is solved. The problem from the original post still remains.

[svenvh]

@svenvh : Coming back to the original bug: Indeed, the problem goes away with -O0, but in the long run this is not what I want.

@davidrohr: yes, using -O0 should only be a temporary work-around.

In general, memset with non-zero argument seems legit, so why isn't the translator handling it?

Currently the translator isn't "robust" enough yet as the focus has mostly been on correctness so far. It knows how to translate certain LLVM IR patterns into SPIR-V. When enabling optimizations, the LLVM IR may look very different and contain constructs we've never encountered before; that's where the translator breaks.

Any estimate when this might be fixed?

It's still on my TODO list, I'll try to put up a fix when I find some time (hopefully soonish now that we've ironed out most of the issues that you found in Clang).

But if the data type is reserved, I would prefer a proper error message (from either clang or the converter) instead of a stack trace.

Fair enough, I have opened #401 to address this in the translator.