Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aarch64 macOS trap on vld1q #1534

Open
DrewRidley opened this issue Sep 19, 2024 · 2 comments
Open

Aarch64 macOS trap on vld1q #1534

DrewRidley opened this issue Sep 19, 2024 · 2 comments
Labels
A-core-arch Area: Necessary for full core::arch support

Comments

@DrewRidley
Copy link

When building a more complex app with NEON intrinsics, I get a runtime trap on vld1q_s32. I did some searching and could not find a tracking issue upstream for this in Cranelift. I additionally tried RUSTFLAGS= "target-feature=-neon" to no avail.

trap at Instance { def: Item(DefId(2:41824 ~ core[8ff7]::core_arch::arm_shared::neon::generated::vld1q_s32_x2)), args: [] } (_ZN4core9core_arch10arm_shared4neon9generated12vld1q_s32_x217hbeca48d3375ec01eE): llvm.aarch64.neon.ld1x2.v4i32.p0i32

While I understand it is not a priority, if I could be pointed to where this set of instructions is being tracked in cranelift I would much appreciate it.

@bjorn3 bjorn3 added the A-core-arch Area: Necessary for full core::arch support label Sep 20, 2024
@bjorn3
Copy link
Member

bjorn3 commented Sep 20, 2024

The general tracking issue for this is #171, but I keep issues for individual intrinsics open too. By the way do you know which crate uses this intrinsic? You should be able to get a backtrace with a debugger.

@DrewRidley
Copy link
Author

    frame #0: 0x00000001071f2808 game`_$LT$$RF$mut$u20$W$u20$as$u20$core..fmt..Write..write_fmt..SpecWriteFmt$GT$::spec_write_fmt::h6a3c139bdf9273a6 at mod.rs:444:32
   thread #12, name = 'Compute Task Pool (4)', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
     frame #0: 0x00000001071f2808 game`_$LT$$RF$mut$u20$W$u20$as$u20$core..fmt..Write..write_fmt..SpecWriteFmt$GT$::spec_write_fmt::h6a3c139bdf9273a6 at mod.rs:444:32
 Target 0: stopped.

With opt-level=0 on LLVM, I do not see that intrinsic used. It seems to get emitted regardless of optimization settings on Cranelift.
I was able to trace this trap back to the crate, zune-jpeg. It has a default feature for neon that I can disable until neon support is more mature.

Thanks again for all your help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-core-arch Area: Necessary for full core::arch support
Projects
None yet
Development

No branches or pull requests

2 participants