-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Atomic Load causes LLVM assertion #6548
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
Comments
@Thiez hope this helps. |
Nevermind, found the issue: In Rust: pub unsafe fn LLVMBuildAtomicLoad(B: BuilderRef,
PointerVal: ValueRef,
Order: AtomicOrdering)
-> ValueRef; In C: extern "C" LLVMValueRef LLVMBuildAtomicLoad(LLVMBuilderRef B,
LLVMValueRef source,
const char* Name,
AtomicOrdering order) The signatures differ. I'm surprised this passed any tests at all, I guess it's pretty hit-and-miss as to whether or not the location contains a 0 or not... |
bors
added a commit
that referenced
this issue
May 17, 2013
This closes #6548 The change makes it match the standard Load signature.
This can be closed |
Fixed by #6550. |
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Jan 15, 2021
Add ui-internal to cargo dev bless changelog: internal
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
intrinsics-atomics
test fails with the following assertion:void llvm::Instruction::setInstructionSubclassData(unsigned short): Assertion
(D & HasMetadataBit) == 0 && "Out of range value put into field"' failed.`. The relevant bit of the stack trace is this:I made a small change to output what AtomicLoad was being given as an ordering:
0xf30eb7a0
though it changes every time.The text was updated successfully, but these errors were encountered: