You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Compiling with rustc (rustc 1.6.0-dev (b14dc5bc1 2015-11-06)) gets:
Stored value type does not match pointer operand type!
store volatile { i32, i32, i32, i32 }* %arg, { i32, i32, i32, i32 }* %dest, align 4
{ i32, i32, i32, i32 }LLVM ERROR: Broken function found, compilation aborted!
Or:
Stored value type does not match pointer operand type!
store volatile %"A<i32>"* %arg, %"A<i32>"* %dest, align 4
%"A<i32>" = type { i32, i32, i32, i32 }LLVM ERROR: Broken function found, compilation aborted!
It looks to me that volatile_store's second argument's value is used without looking at platform ABI requirements (ie using the load).
volatile_load might also be affected.
Also, LLVM error formatting weirdness.
The text was updated successfully, but these errors were encountered:
huonw
added
A-LLVM
Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
labels
Nov 6, 2015
A quick fix would be to make volatile_read and volatile_write use std::intrinsics::volatile_copy_nonoverlapping_memory. However the downside is that this intrinsic will force both a volatile load and store to perform the copy.
It seems that Clang will use a simple volatile load/store for primitive types but will fall back to a volatile memcpy for struct types.
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Compiling with
rustc
(rustc 1.6.0-dev (b14dc5bc1 2015-11-06)
) gets:Or:
It looks to me that
volatile_store
's second argument's value is used without looking at platform ABI requirements (ie using the load).volatile_load
might also be affected.Also, LLVM error formatting weirdness.
The text was updated successfully, but these errors were encountered: