Problem with passing struct to C function on windows #11198
Comments
ghost
mentioned this issue
|
Can you provide a slightly more minimized test case? It would also be useful to have content hosted in a github gist instead of a 7z archive that's much more easily accessible. |
|
Thanks! cc @jld, @nikomatsakis |
|
It appears that gcc treats the struct as an immediate 32-bit value (one register), and our call to the function generate a function call with 4 arguments. I would copy-paste more assembly, but I'm not sure how to copy out of a windows VM... |
|
These parts are probably relevant: windows_internal_llvm.asm was generated by LLVM integrated with rust Are there some parameters passed to integrated LLVM that could cause this? |
|
I wrote a small utility to bypass the problem: https://gist.github.com/krzat/8374078 |
[`slow_vector_initialization`]: catch `Vec::new()` followed by `.resize(len, 0)` Closes rust-lang#10938 changelog: [`slow_vector_initialization`]: catch `Vec::new()` followed by `.resize(len, 0)`
…=xFrednet,djc [`slow_vector_initialization`]: clarify why `Vec::new()` + resize is worse rust-lang#11198 extended this lint to also warn on `Vec::new()` + `resize(0, len)`, but did not update the lint documentation, so it left some confused (rust-lang/rust-clippy#10938 (comment)). This PR should make it a bit more clear. (cc `@djc` `@vi` what do you think about this?) <details> <summary>More details</summary> Godbolt for `Vec::new()` + `.resize(x, 0)`: https://godbolt.org/z/e7q9xc9rG The resize call first does a normal allocation (`__rust_alloc`): ```asm alloc::raw_vec::finish_grow: ... cmp qword ptr [rcx + 8], 0 je .LBB1_7 ; if capacity == 0 -> LBB1_7 .LBB1_7: ... call qword ptr [rip + __rust_alloc@GOTPCREL] ``` *Then* a memset for zero initialization: ```asm example::f: ... xor esi, esi ; 0 call qword ptr [rip + memset@GOTPCREL] ``` ------------ Godbolt for `vec![0; len]`: https://godbolt.org/z/M3vr53vWY Important bit: ```asm example::f: ... call qword ptr [rip + __rust_alloc_zeroed@GOTPCREL] ``` </details> changelog: [`slow_vector_initialization`]: clarify why `Vec::new()` + resize is worse than `vec![0; len]`
I prepared some files that should illustrate the problem: click
Struct Color is passed incorrectly to function in C library. I pass {1,2,3,4} but receive {1,0,0,0}.
It happens on Windows 7 64bit, but not on Linux Mint 64bit.
Using external LLVM to compile bitcode (on Windows) works too.
The text was updated successfully, but these errors were encountered: