intel
[SYCL] Creating a buffer from a vector results in a linker crash
Describe the bug
While trying to test something entirely different, I found that a way in which I've set up buffer objects in the past for tests, is apparently not working anymore. The compilation crashes... At least I think the trigger is how the sycl::buffer object is created in the test. But I'm really not sure.
To Reproduce
I can make the compiler crash with something as simple as the following:
// SYCL include(s).
#include <CL/sycl.hpp>
// STL include(s).
#include <vector>
int main() {
// Set up the queue.
cl::sycl::queue queue;
// Set up some variables.
static constexpr std::size_t BUFFER_SIZE = 1000;
std::vector< float > hostVector( BUFFER_SIZE, 1.23f );
cl::sycl::buffer< float, 1 > deviceBuffer( hostVector.data(), BUFFER_SIZE );
// Submit a trivial job using the buffer.
using am = cl::sycl::access::mode;
queue.submit( [&]( cl::sycl::handler& h ) {
auto acc = deviceBuffer.get_access< am::read_write >( h );
h.parallel_for< class LinearTransform >(
cl::sycl::range< 1 >( BUFFER_SIZE ),
[=]( cl::sycl::id< 1 > id ) {
if( id >= BUFFER_SIZE ) {
return;
}
acc[ id ] = acc[ id ] * 2;
} );
} );
queue.wait_and_throw();
return 0;
}
It makes both the latest DPC++ version, and a not-too-old private build of the compiler crash. Though they do crash a little differently... :confused:
[bash][Elrond]:array > dpcpp buffer_bug.cxx
LLVM ERROR: llvm.memmove of non-constant length not supported
PLEASE submit a bug report to https://software.intel.com/en-us/support/priority-support and include the crash backtrace.
Stack dump:
0. Program arguments: /data/software/intel/oneapi/compiler/2021.2.0/linux/bin/llvm-spirv -o /tmp/buffer_bug-a4af6c-d40be3.spv -spirv-max-version=1.1 -spirv-debug-info-version=legacy -spirv-allow-extra-diexpressions -spirv-ext=+all,-SPV_INTEL_usm_storage_classes /tmp/buffer_bug-53911c.bc
1. Running pass 'Lower llvm.memmove into llvm.memcpy' on module '/tmp/buffer_bug-53911c.bc'.
#0 0x0000559748fec3aa llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/software/intel/oneapi/compiler/2021.2.0/linux/bin/llvm-spirv+0x6103aa)
#1 0x0000559748fec820 llvm::sys::RunSignalHandlers() (/data/software/intel/oneapi/compiler/2021.2.0/linux/bin/llvm-spirv+0x610820)
#2 0x0000559748fec770 SignalHandler(int) (/data/software/intel/oneapi/compiler/2021.2.0/linux/bin/llvm-spirv+0x610770)
#3 0x00007faa41e86980 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12980)
#4 0x00007faa41ac1fb7 raise /build/glibc-S9d2JN/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#5 0x00007faa41ac3921 abort /build/glibc-S9d2JN/glibc-2.27/stdlib/abort.c:81:0
#6 0x0000559748fd66ab (/data/software/intel/oneapi/compiler/2021.2.0/linux/bin/llvm-spirv+0x5fa6ab)
#7 0x0000559748ea74e5 (/data/software/intel/oneapi/compiler/2021.2.0/linux/bin/llvm-spirv+0x4cb4e5)
#8 0x0000559749133420 SPIRV::SPIRVLowerMemmove::visitMemMoveInst(llvm::MemMoveInst&) (/data/software/intel/oneapi/compiler/2021.2.0/linux/bin/llvm-spirv+0x757420)
#9 0x0000559749132a65 SPIRV::SPIRVLowerMemmove::runOnModule(llvm::Module&) (/data/software/intel/oneapi/compiler/2021.2.0/linux/bin/llvm-spirv+0x756a65)
#10 0x0000559748e76d86 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/data/software/intel/oneapi/compiler/2021.2.0/linux/bin/llvm-spirv+0x49ad86)
#11 0x000055974910628e llvm::writeSpirv(llvm::Module*, SPIRV::TranslatorOpts const&, std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) (/data/software/intel/oneapi/compiler/2021.2.0/linux/bin/llvm-spirv+0x72a28e)
#12 0x0000559749080222 main (/data/software/intel/oneapi/compiler/2021.2.0/linux/bin/llvm-spirv+0x6a4222)
#13 0x00007faa41aa4bf7 __libc_start_main /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:344:0
#14 0x000055974907aa8e _start (/data/software/intel/oneapi/compiler/2021.2.0/linux/bin/llvm-spirv+0x69ea8e)
llvm-foreach: Aborted (core dumped)
dpcpp: error: llvm-spirv command failed with exit code 1 (use -v to see invocation)
[bash][Elrond]:array >
[bash][Elrond]:array > clang++ -fsycl buffer_bug.cxx
LLVM ERROR: Type mismatch in constant table!
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: /data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin/llvm-link /tmp/buffer_bug-5f6208.bc -o /tmp/buffer_bug-f27ecc.bc --suppress-warnings
#0 0x000055f0dfb70aec llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin/llvm-link+0x262aec)
#1 0x000055f0dfb6ea64 llvm::sys::RunSignalHandlers() (/data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin/llvm-link+0x260a64)
#2 0x000055f0dfb6ebd3 SignalHandler(int) Signals.cpp:0:0
#3 0x00007fab294ec980 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12980)
#4 0x00007fab283a1fb7 raise /build/glibc-S9d2JN/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#5 0x00007fab283a3921 abort /build/glibc-S9d2JN/glibc-2.27/stdlib/abort.c:81:0
#6 0x000055f0dfb37996 llvm::report_fatal_error(llvm::Twine const&, bool) (/data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin/llvm-link+0x229996)
#7 0x000055f0dfb37ac8 (/data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin/llvm-link+0x229ac8)
#8 0x000055f0df9cfdb3 llvm::BitcodeReaderValueList::getConstantFwdRef(unsigned int, llvm::Type*) (/data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin/llvm-link+0xc1db3)
#9 0x000055f0df9a5531 (anonymous namespace)::BitcodeReader::parseConstants() BitcodeReader.cpp:0:0
#10 0x000055f0df9ac97e (anonymous namespace)::BitcodeReader::parseFunctionBody(llvm::Function*) BitcodeReader.cpp:0:0
#11 0x000055f0df9b07a3 (anonymous namespace)::BitcodeReader::materialize(llvm::GlobalValue*) BitcodeReader.cpp:0:0
#12 0x000055f0dfaad32a llvm::Module::materialize(llvm::GlobalValue*) (/data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin/llvm-link+0x19f32a)
#13 0x000055f0dfa76364 llvm::GlobalValue::materialize() (/data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin/llvm-link+0x168364)
#14 0x000055f0dfafbc69 (anonymous namespace)::IRLinker::materialize(llvm::Value*, bool) IRMover.cpp:0:0
#15 0x000055f0dfb7b70d (anonymous namespace)::Mapper::mapValue(llvm::Value const*) ValueMapper.cpp:0:0
#16 0x000055f0dfb7c53b (anonymous namespace)::Mapper::remapInstruction(llvm::Instruction*) ValueMapper.cpp:0:0
#17 0x000055f0dfb7cb61 (anonymous namespace)::Mapper::remapFunction(llvm::Function&) ValueMapper.cpp:0:0
#18 0x000055f0dfb7d133 (anonymous namespace)::Mapper::flush() ValueMapper.cpp:0:0
#19 0x000055f0dfb7d36c llvm::ValueMapper::mapValue(llvm::Value const&) (/data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin/llvm-link+0x26f36c)
#20 0x000055f0dfb02a0f llvm::IRMover::move(std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >, llvm::ArrayRef<llvm::GlobalValue*>, std::function<void (llvm::GlobalValue&, std::function<void (llvm::GlobalValue&)>)>, bool) (/data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin/llvm-link+0x1f4a0f)
#21 0x000055f0dfb0b160 (anonymous namespace)::ModuleLinker::run() LinkModules.cpp:0:0
#22 0x000055f0dfb0bfcb llvm::Linker::linkInModule(std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >, unsigned int, std::function<void (llvm::Module&, llvm::StringSet<llvm::MallocAllocator> const&)>) (/data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin/llvm-link+0x1fdfcb)
#23 0x000055f0df989a57 linkFiles(char const*, llvm::LLVMContext&, llvm::Linker&, llvm::cl::list<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, llvm::cl::parser<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, unsigned int) llvm-link.cpp:0:0
#24 0x000055f0df977be9 main (/data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin/llvm-link+0x69be9)
#25 0x00007fab28384bf7 __libc_start_main /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:344:0
#26 0x000055f0df98684a _start (/data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin/llvm-link+0x7884a)
clang-13: error: unable to execute command: Aborted (core dumped)
clang-13: error: sycl-link command failed due to signal (use -v to see invocation)
clang version 13.0.0 (https://github.com/intel/llvm.git 6fc78b68d36470e50841bcc17e054ff30dc6d31e)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin
clang-13: note: diagnostic msg: Error generating preprocessed source(s).
[bash][Elrond]:array >
Environment (please complete the following information):
- OS: Ubuntu 18.04
- Target device and vendor: N/A
- DPC++ version:
[bash][Elrond]:array > dpcpp -v
Intel(R) oneAPI DPC++ Compiler 2021.2.0 (2021.2.0.20210317)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /data/software/intel/oneapi/compiler/2021.2.0/linux/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Candidate multilib: .;@m64
Selected multilib: .;@m64
[bash][Elrond]:array >
[bash][Elrond]:array > clang++ -v
clang version 13.0.0 (https://github.com/intel/llvm.git 6fc78b68d36470e50841bcc17e054ff30dc6d31e)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /data/software/intel/clang/13.0.0-2021-04-22/x86_64-ubuntu1804-gcc8-opt/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Candidate multilib: .;@m64
Selected multilib: .;@m64
Found CUDA installation: /data/software/cuda/10.2.89/x86_64-ubuntu1804, version 10.2
[bash][Elrond]:array >
- Dependencies version: N/A
Additional context
I checked that even some older test sources of mine, which use this sort of formalism, would crash the same way as well. Of course those tests did work fine in the past.
Pinging @ivorobts.
@krasznaa on the contrary, I think buffer is ok. But I find it suspicious, that you capture a contexpr static variable by value. I'm not sure it is allowed. Like, what should be the behavior, if you decide to change the value of that variable inside kernel. Also, the backtrace points to spirv translator.
Tagging @AlexeySachkov @AlexeySotkin
Aaargh... :angry:
No, it's not he buffer after all. It's how the kernel tries to compare the value of sycl::id<1> to the std::size_t constant. If I remove that, the build succeeds. I thought that I would be free to use the BUFFER_SIZE variable in the kernel, but apparently not.
And I see your comment now as well. :stuck_out_tongue:
It does... (Simply removing that one keyword makes the build succeed.)
:thinking: I'm always just using constexpr together with static. Not because of some deep idea behind all of it, just because I'm mostly replacing static const variables with constexpr ones. In the end, behaviour-wise static constexpr and constexpr should not be all too different, or should they be?
I think I more or less understand what the issue is. I'm just not sure if what I wrote should be considered valid code or not. The compiler should definitely not crash on it, but you're right that the code itself could also produce a compilation error in the end.
behaviour-wise
static constexprandconstexprshould not be all too different, or should they be?
It's a common misconception, that constexpr values will be evaluated in compile time. Compiler may still emit some code for those constructions. Like in your case, the code may actually try to reference BUFFER_SIZE inside your lambda. See my example: https://godbolt.org/z/75YjYG4hz The compiler had to actually emit something for Foo for me to be able to take it's address. Without static keyword, BUFFER_SIZE is not required to actually be a global object in that case. However, I have a very limited understanding, why this particular use-case fails to compile. Reading SYCL spec actually suggests, that it should work.
I guess, C++20's consteval will save us, so you may try it as well.
The compiler should definitely not crash on it
I agree
@krasznaa on the contrary, I think buffer is ok. But I find it suspicious, that you capture a contexpr static variable by value. I'm not sure it is allowed. Like, what should be the behavior, if you decide to change the value of that variable inside kernel. Also, the backtrace points to spirv translator.
constexpr implies const, so any modifications won't be allowed and therefore it shouldn't matter whether the variable is global (implied by static) or not. From https://en.cppreference.com/w/cpp/language/constexpr:
A constexpr specifier used in an object declaration "or non-static member function (until C++14)" implies const.
No, it's not he buffer after all. It's how the kernel tries to compare the value of sycl::id<1> to the std::size_t constant. If I remove that, the build succeeds. LLVM ERROR: llvm.memmove of non-constant length not supported
It is surprising for me that such simple kernel contains non-constant length memmove within it and it is even more surprising that it is triggered by that "if".
My test shows the following error when the keyword 'static' is not removed in the codes:
While deleting: void (%"union._ZTSSt9_Any_data.std::_Any_data"*, %"class._ZTSN2cl4sycl7handlerE.cl::sycl::handler"*)* %
Use still stuck around after Def is destroyed: store void (%"union._ZTSSt9_Any_data.std::_Any_data"*, %"class._ZTSN2cl4sycl7handlerE.cl::sycl::handler"*)* <badref>, void (%"union._ZTSSt9_Any_data.std::_Any_data"*, %"class._ZTSN2cl4sycl7handlerE.cl::sycl::handler"*)** %_M_invoker.i.i.i, align 8, !tbaa !94, !noalias !91
clang-13: /home/user/llvm/llvm/lib/IR/Value.cpp:105: llvm::Value::~Value(): Assertion `materialized_use_empty() && "Uses remain when a value is destroyed!"' failed.
With the compiler build from latest sources of intel/llvm, I got the following assertion:
clang-13: llvm/llvm/lib/IR/Constants.cpp:2223: static llvm::Constant* llvm::ConstantExpr::getBitCast(llvm::Constant*, llvm::Type*, bool): Assertion `CastInst::castIsValid(Instruction::Bi
tCast, C, DstTy) && "Invalid constantexpr bitcast!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.>-Program arguments: llvm/build/bin/clang-13 -cc1 -triple spir64-unknown-unknown-sycldevice -aux-triple x86_64-unknown-linux-gnu -fsycl-is-device -fdeclare-spirv-builtins -mllvm -sycl-
opt -Wno-sycl-strict -fsycl-int-header=/tmp/test-header-6dbf47.h -sycl-std=2020 -fsycl-unique-prefix=4ec47e0d214072ef -Wspir-compat -emit-llvm-bc -emit-llvm-uselists -disable-free -main-
file-name test.cpp -mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math -fno-verbose-asm -mconstructor-aliases -aux-target-cpu x86-64 -debugger-tuning=gdb -fcove
rage-compilation-dir=/testing/issue-3732 -resource-dir llvm/build/lib/clang/13.0.0 -internal-isystem llvm/build/bin/../include/sycl -internal-isystem llvm/build/bin/../include -internal-
isystem /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/x86_64-linux-gnu/c++/7.5.0 -internal-i
system /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/backward -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0 -internal-isystem /u
sr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/x86_64-linux-gnu/c++/7.5.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/backward -internal-is
ystem llvm/build/lib/clang/13.0.0/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../x86_64-linux-gnu/include -internal-extern
c-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -internal-isystem llvm/build/lib/clang/13.0.0/include -internal-isystem
/usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-is
ystem /include -internal-externc-isystem /usr/include -std=c++17 -fdeprecated-macro -fdebug-compilation-dir=/testing/issue-3732 -ferror-limit 19 -fgnuc-version=4.2.1 -fcxx-exceptions -fe
xceptions -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/test-8dcdb9.bc -x c++ test.cpp
1.>-<eof> parser at end of file
2.>-Per-file LLVM IR generation
3.>-/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/x86_64-linux-gnu/c++/7.5.0/bits/gthr-default.h:247:1: Generating code for declaration '__gthread_active_p'
#0 0x00005633c267105f PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
#1 0x00005633c266e8ad SignalHandler(int) Signals.cpp:0:0
#2 0x00007f608b25a890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
#3 0x00007f6089f0be97 raise /build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#4 0x00007f6089f0d801 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0
#5 0x00007f6089efd39a __assert_fail_base /build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0
#6 0x00007f6089efd412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412)
#7 0x00005633c1ed60c7 (llvm/build/bin/clang-13+0x19b50c7)
#8 0x00005633c2a7c43f clang::CodeGen::CodeGenModule::GetWeakRefReference(clang::ValueDecl const*) (llvm/build/bin/clang-13+0x255b43f)
#9 0x00005633c29a2eb2 clang::CodeGen::ConstantEmitter::tryEmitPrivate(clang::APValue const&, clang::QualType) (llvm/build/bin/clang-13+0x2481eb2)
#10 0x00005633c29a4739 clang::CodeGen::ConstantEmitter::emitAbstract(clang::SourceLocation, clang::APValue const&, clang::QualType) (llvm/build/bin/clang-13+0x2483739)
#11 0x00005633c2c81870 clang::CodeGen::CodeGenFunction::tryEmitAsConstant(clang::DeclRefExpr*) (llvm/build/bin/clang-13+0x2760870)
#12 0x00005633c2cc22dc (anonymous namespace)::ScalarExprEmitter::Visit(clang::Expr*) CGExprScalar.cpp:0:0
#13 0x00005633c129274c (anonymous namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*) CGExprScalar.cpp:0:0
#14 0x00005633c2cc21fb (anonymous namespace)::ScalarExprEmitter::Visit(clang::Expr*) CGExprScalar.cpp:0:0
#15 0x00005633c2cc35be (anonymous namespace)::ScalarExprEmitter::EmitBinOps(clang::BinaryOperator const*) CGExprScalar.cpp:0:0
#16 0x00005633c2cc3aa8 (anonymous namespace)::ScalarExprEmitter::EmitCompare(clang::BinaryOperator const*, llvm::CmpInst::Predicate, llvm::CmpInst::Predicate, llvm::CmpInst::Predicate, b
ool) CGExprScalar.cpp:0:0
#17 0x00005633c2cc0aae (anonymous namespace)::ScalarExprEmitter::Visit(clang::Expr*) CGExprScalar.cpp:0:0
#18 0x00005633c1292ce0 (anonymous namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*) CGExprScalar.cpp:0:0
#19 0x00005633c2cc21fb (anonymous namespace)::ScalarExprEmitter::Visit(clang::Expr*) CGExprScalar.cpp:0:0
#20 0x00005633c2cc2a46 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) (llvm/build/bin/clang-13+0x27a1a46)
#21 0x00005633c29bb2f5 clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) (llvm/build/bin/clang-13+0x249a2f5)
#22 0x00005633c29c228d clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef<clang::Attr const*>) (llvm/build/bin/clang-13+0x24a128d)
#23 0x00005633c29c6a4c clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) (llvm/build/bin/clang-13+0x24a5a4c)
etc
@AaronBallman , @elizabethandrews , @premanandrao FYI
The error LLVM ERROR: llvm.memmove of non-constant length not supported should have been fixed though.
I am unable to reproduce. Using both the latest build of intel/llvm here as well as an up-to-date private internal build of the compiler. Both compile and link fine.
clang++ -fsycl -o lc.bin linker_crash.cpp where linker_crash.cpp is the code at the top of this report.
@krasznaa - could you confirm?
Yepp, this seems to have been fixed in one way or another a long time ago as it seems.