decltype(auto) llvm::cast(From*) [with To = llvm::VectorType; From = llvm::Type]: Assertion `isa<To>(Val) && "cast<Ty>() argument of incompatible type!

[ZuseZ4]

[compiler/rustc_codegen_llvm/src/llvm/ffi.rs:936:5] &fnc = (ptr:; Function Attrs: mustprogress nofree noinline nosync nounwind nonlazybind sanitize_hwaddress willreturn memory(argmem: read) uwtable
define internal noundef double @_ZN2ad3foo17h1df3884f5e83c68dE(ptr noalias nocapture noundef readonly align 8 dereferenceable(8) %0) unnamed_addr #5 {
  %2 = load double, ptr %0, align 8, !noundef !6
  %3 = tail call double @llvm.sin.f64(double %2)
  ret double %3
}
)
[compiler/rustc_codegen_llvm/src/llvm/ffi.rs:958:5] &primary_ret = true
[compiler/rustc_codegen_llvm/src/llvm/ffi.rs:959:5] &ret_activity = DFT_OUT_DIFF
[compiler/rustc_codegen_llvm/src/llvm/ffi.rs:960:5] &input_activity = [
    DFT_DUP_ARG,
]
num_fnc_args: 1
input_activity.len(): 1
[compiler/rustc_codegen_llvm/src/llvm/ffi.rs:983:5] &res = (ptr:; Function Attrs: mustprogress nofree noinline nosync nounwind nonlazybind sanitize_hwaddress willreturn memory(argmem: readwrite) uwtable
define internal { double } @diffe_ZN2ad3foo17h1df3884f5e83c68dE(ptr noalias nocapture noundef readonly align 8 dereferenceable(8) %0, ptr nocapture align 8 %1, double %2) unnamed_addr #111 {
  %4 = load double, ptr %0, align 8, !alias.scope !41888, !noalias !41891, !noundef !6
  %5 = tail call double @llvm.sin.f64(double %4) #112
  %6 = call fast double @llvm.cos.f64(double %4)
  %7 = fmul fast double %2, %6
  %8 = load double, ptr %1, align 8, !alias.scope !41891, !noalias !41888
  %9 = fadd fast double %8, %7
  store double %9, ptr %1, align 8, !alias.scope !41891, !noalias !41888
  %10 = insertvalue { double } undef, double %5, 0
  ret { double } %10
}
)
rustc: /h/344/drehwald/prog/rust/src/llvm-project/llvm/include/llvm/Support/Casting.h:578: decltype(auto) llvm::cast(From*) [with To = llvm::VectorType; From = llvm::Type]: Assertion `isa<To>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
warning: `ad` (bin "ad") generated 2 warnings (run `cargo fix --bin "ad"` to apply 1 suggestion)
error: could not compile `ad` (bin "ad"); 2 warnings emitted

[ZuseZ4]

This broke on one of my updates, afaik now every example fails with this Type error. Did something on the Enzyme side change, or do I need to debug from the Rust side?

[wsmoses]

Can you add the backtrace?

[jedbrown]

I don't know the right way to get a backtrace in this context, but I updated Enzyme to 3e2de5de6c03b9fe138d657ebfde42fa05af3a4e and rebuilt, attached gdb, and got this.

rustc: /home/jed/src/rust-enzyme/src/llvm-project/llvm/include/llvm/Support/Casting.h:578: decltype(auto) llvm::cast(From*) [with To = VectorType; From = Type]: Assertion `isa<To>(Val) && "cast<Ty>() argument of incompatible type!"' failed.

Thread 4 "coordinator" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe00006c0 (LWP 3770409)]
0x00007ffff36ab32c in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff36ab32c in ?? () from /usr/lib/libc.so.6
#1  0x00007ffff365a6c8 in raise () from /usr/lib/libc.so.6
#2  0x00007ffff36424b8 in abort () from /usr/lib/libc.so.6
#3  0x00007ffff36423dc in ?? () from /usr/lib/libc.so.6
#4  0x00007ffff3652d46 in __assert_fail () from /usr/lib/libc.so.6
#5  0x00007fffeba62db7 in LLVMGetElementType () from /home/jed/src/rust-enzyme/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/../lib/libLLVM-17-rust-1.77.0-nightly.so
#6  0x00007ffff42c97b4 in <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::write::WriteBackendMethods>::autodiff ()
   from /home/jed/src/rust-enzyme/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/librustc_driver-65cc4792955af6d5.so
#7  0x00007ffff42e6c1d in <rustc_codegen_ssa::back::lto::LtoModuleCodegen<rustc_codegen_llvm::LlvmCodegenBackend>>::autodiff ()
   from /home/jed/src/rust-enzyme/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/librustc_driver-65cc4792955af6d5.so
#8  0x00007ffff439a920 in rustc_codegen_ssa::back::write::generate_lto_work::<rustc_codegen_llvm::LlvmCodegenBackend> ()
   from /home/jed/src/rust-enzyme/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/librustc_driver-65cc4792955af6d5.so
#9  0x00007ffff42b4641 in std::sys_common::backtrace::__rust_begin_short_backtrace::<<rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::ExtraBackendMethods>::spawn_named_thread<rustc_codegen_ssa::back::write::start_executing_work<rustc_codegen_llvm::LlvmCodegenBackend>::{closure#5}, core::result::Result<rustc_codegen_ssa::back::write::CompiledModules, ()>>::{closure#0}, core::result::Result<rustc_codegen_ssa::back::write::CompiledModules, ()>> () from /home/jed/src/rust-enzyme/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/librustc_driver-65cc4792955af6d5.so
#10 0x00007ffff43a58a4 in <<std::thread::Builder>::spawn_unchecked_<<rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::ExtraBackendMethods>::spawn_named_thread<rustc_codegen_ssa::back::write::start_executing_work<rustc_codegen_llvm::LlvmCodegenBackend>::{closure#5}, core::result::Result<rustc_codegen_ssa::back::write::CompiledModules, ()>>::{closure#0}, core::result::Result<rustc_codegen_ssa::back::write::CompiledModules, ()>>::{closure#1} as core::ops::function::FnOnce<()>>::call_once::{shim:vtable#0} ()
   from /home/jed/src/rust-enzyme/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/librustc_driver-65cc4792955af6d5.so
#11 0x00007ffff7ecb575 in std::sys::unix::thread::Thread::new::thread_start () from /home/jed/src/rust-enzyme/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/libstd-986b42e05a394a44.so
#12 0x00007ffff36a955a in ?? () from /usr/lib/libc.so.6
#13 0x00007ffff3726a3c in ?? () from /usr/lib/libc.so.6

[wsmoses]

That looks like the LLVMGetElementType is being called from within the rust autodiff code, and specifically it's trying to get the element type of something which is not a vector/array (That method only works on vectors and arrays, not pointers, structs, etc).

A debug build may make that easier to find, but @ZuseZ4 does that provide sufficient of a clue for you to look for what's going wrong?

[wsmoses]

This perhaps is related to opaque pointers (aka now pointers don't have element types), so perhaps that's what's going awry?

[ZuseZ4]

Yes, that's just what I was looking for, thanks a lot. Completely missed that I might also need to remove those from the Rust side.

[ZuseZ4]

Fixed opaque ptr handling, examples now run and produce correct results in debug mode. However under release mode it segfaults (illegal hw instruction), going to create a new issue. @jedbrown, that should at least allow you to get started. Fixed by #a74948f