Skip to content

Clang crashes since last pulldowns when building shared objects #4294

Closed
@Michoumichmich

Description

@Michoumichmich

Describe the bug
Since last week I'm experiencing crashes when building SYCL projects. All the crashes happens when linking the SYCL back-end of that library into a shared object.

When targeting the CUDA back-end, I get the following crashes:
I get, when building with -Og:

While deleting: %"class._ZTSN2cl4sycl5rangeILi3EEE.cl::sycl::range" ()* %
Use still stuck around after Def is destroyed:i8* bitcast (%"class._ZTSN2cl4sycl5rangeILi3EEE.cl::sycl::range" ()* <badref> to i8*)
Use still stuck around after Def is destroyed:  %call = call %"class._ZTSN2cl4sycl5rangeILi3EEE.cl::sycl::range" <badref>() #25, !dbg !58
clang-14: /home/michel/sycl_workspace/llvm/llvm/lib/IR/Value.cpp:103: llvm::Value::~Value(): Assertion `materialized_use_empty() && "Uses remain when a value is destroyed!"' 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: /home/michel/sycl_workspace/deploy/bin/clang-14 -cc1 -triple nvptx64-nvidia-cuda -aux-triple x86_64-unknown-linux-gnu -fsycl-is-device -fdeclare-spirv-builtins -sycl-std=2020 -fsycl-std-layout-kernel-params -S -disable-free -main-file-name zfp.c.o -mrelocation-model pic -pic-level 2 -fhalf-no-semantic-interposition -mframe-pointer=all -ffp-contract=on -fno-rounding-math -fno-verbose-asm -no-integrated-as -aux-target-cpu x86-64 -internal-isystem /home/michel/sycl_workspace/deploy/bin/../include/sycl -internal-isystem /home/michel/sycl_workspace/deploy/bin/../include -mlink-builtin-bitcode /home/michel/sycl_workspace/deploy/lib/clang/14.0.0/../../clc/libspirv-nvptx64--nvidiacl.bc -mlink-builtin-bitcode /usr/local/cuda-11.4/nvvm/libdevice/libdevice.10.bc -target-feature +ptx72 -target-sdk-version=11.2 -target-cpu sm_75 -mllvm -treat-scalable-fixed-error-as-warning -debug-info-kind=line-directives-only -dwarf-version=2 -debugger-tuning=gdb -fno-dwarf-directory-asm -v -resource-dir /home/michel/sycl_workspace/deploy/lib/clang/14.0.0 -Og -Wall -Wextra -Wshadow -Wdouble-promotion -Winit-self -Wuninitialized -Wmissing-declarations -Woverloaded-virtual -Wall -Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization -Wformat=2 -Winit-self -Wmissing-declarations -Wmissing-include-dirs -Woverloaded-virtual -Wredundant-decls -Wshadow -Wsign-conversion -Wsign-promo -Wstrict-overflow=5 -Wno-c++20-extensions -Wno-undef -Wno-unused -Wno-unused-parameter -Wno-unknown-cuda-version -pedantic -std=c++20 -fdebug-compilation-dir=/tmp/tmp.QgqHvAUwXa/cmake-build-debug/src -ferror-limit 19 -fgnuc-version=4.2.1 -fno-implicit-modules -fcolor-diagnostics -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/zfp-f738b8-d50538.s -x ir /tmp/zfp-350792.bc
1.	Code generation
2.	Running pass 'Add implicit SYCL global offset' on module '/tmp/zfp-350792.bc'.

And when building for release with -O2, the previous error disappear and I get this one instead:

clang-14: /home/michel/sycl_workspace/llvm/llvm/lib/Target/NVPTX/SYCL/LocalAccessorToSharedMemory.cpp:206: llvm::Function *(anonymous namespace)::LocalAccessorToSharedMemory::ProcessFunction(llvm::Module &, llvm::Function *): Assertion `F->use_empty()' 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: /home/michel/sycl_workspace/deploy/bin/clang-14 -cc1 -triple nvptx64-nvidia-cuda -aux-triple x86_64-unknown-linux-gnu -fsycl-is-device -fdeclare-spirv-builtins -sycl-std=2020 -fsycl-std-layout-kernel-params -S -disable-free -main-file-name zfp.c.o -mrelocation-model pic -pic-level 2 -fhalf-no-semantic-interposition -mframe-pointer=all -ffp-contract=on -fno-rounding-math -fno-verbose-asm -no-integrated-as -aux-target-cpu x86-64 -internal-isystem /home/michel/sycl_workspace/deploy/bin/../include/sycl -internal-isystem /home/michel/sycl_workspace/deploy/bin/../include -mlink-builtin-bitcode /home/michel/sycl_workspace/deploy/lib/clang/14.0.0/../../clc/libspirv-nvptx64--nvidiacl.bc -mlink-builtin-bitcode /usr/local/cuda-11.4/nvvm/libdevice/libdevice.10.bc -target-feature +ptx72 -target-sdk-version=11.2 -target-cpu sm_75 -mllvm -treat-scalable-fixed-error-as-warning -debugger-tuning=gdb -fno-dwarf-directory-asm -resource-dir /home/michel/sycl_workspace/deploy/lib/clang/14.0.0 -O3 -Wno-unknown-cuda-version -std=c++20 -fdebug-compilation-dir=/tmp/tmp.QgqHvAUwXa/cmake-build-release/src -ferror-limit 19 -fgnuc-version=4.2.1 -fno-implicit-modules -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/zfp-f9854a-16efb3.s -x ir /tmp/zfp-4c499c.bc
1.	Code generation
2.	Running pass 'localaccessortosharedmemory' on module '/tmp/zfp-4c499c.bc'.

On the SPIR-V back-end (spir64_x86_64), the use of a right funnel shifter:

inline uint32_t funnelshift_r(uint32_t lo, uint32_t hi, uint32_t shift) {
        if (shift == 0) return lo; // To avoid shifting by 32
        return (lo >> shift % 31) | (hi << (32 - (shift % 31)));
}

Results now in the following error:

InvalidFunctionCall: Unexpected llvm intrinsic:
 llvm.fshr.i32

Replacing the shifter implementation by return 0 allows the code to compile on the spir-v back-end, and without any of the previously mentioned errors. But the behaviour is obviously wrong.

Everything compiles fine with older versions such as 8b56cbb on all the targets.

** Reproducer **
I wasn't able to write a reproducer. I'm compiling with -fsycl-targets=nvptx64-nvidia-cuda -Xsycl-target-backend=nvptx64-nvidia-cuda --cuda-gpu-arch=sm_75. I can link the source code with build instructions if needed.

Environment:

  • OS: Linux RHEL 8.4
  • Target device and vendor: Intel CPU and Nvidia CUDA
  • DPC++ version: 69e78f8

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingcompilerCompiler related issuecudaCUDA back-end

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions