[Bug c/86727] New: Struct argument in xmm0 register instead of rcx on Win64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86727 Bug ID: 86727 Summary: Struct argument in xmm0 register instead of rcx on Win64 Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bart at bartjanssens dot org Target Milestone: --- Created attachment 44462 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44462&action=edit Test case When passing a struct containing a single value of type double, the argument is fetched from the %xmm0 register, where the %rcx register should actually be used on 64 bit Windows. Both mingw GCC 6.4.0 and 8.2.0 read the argument like this: movsd %xmm0, 16(%rbp) Clang and MSVC both read correctly from %rcx. Attached is a self-contained example, assembly dumped with x86_64-w64-mingw32-gcc -S -o - -x c test.c shows the problem. More discussion is also at: https://github.com/JuliaLang/julia/issues/28325 When changing the field type to e.g. int or when adding extra fields to the struct the problem goes away.
[Bug target/64243] Passing and returning structures with single member of floating type via SSE registers is wrong on Windows x86-64 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64243 --- Comment #2 from Bart Janssens --- Any chance that this can be upgraded to "confirmed"? Seems this has been around for a while...
[Bug target/64243] Passing and returning structures with single member of floating type via SSE registers is wrong on Windows x86-64 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64243 Bart Janssens changed: What|Removed |Added CC||bart at bartjanssens dot org --- Comment #3 from Bart Janssens --- We are still having this issue, it now manifests in cross-compiled binaries used in the Julia ecosystem, see: https://github.com/JuliaPackaging/BinaryBuilder.jl/issues/315
[Bug target/64243] Passing and returning structures with single member of floating type via SSE registers is wrong on Windows x86-64 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64243 --- Comment #7 from Bart Janssens --- Thanks, confirmed that this is also working on GCC 10.2. Unfortunately the latest in our compiler images is 9.1, and that seems to be still affected, so we'll have to upgrade.
[Bug c++/105779] New: internal_error on passing a pointer to static function to another function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105779 Bug ID: 105779 Summary: internal_error on passing a pointer to static function to another function Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bart at bartjanssens dot org Target Milestone: --- Created attachment 53054 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53054&action=edit Minimal example to reproduce this Compiling the attached test case fails, explicitly adding & on line 23 to indicate that method takes a pointer to a function solves the problem, but I believe both should compile (and did prior to GCC 12), and certainly not crash. Compile command: g++ -Wall -Wextra test-pointer.cpp Output: during RTL pass: expand test-pointer.cpp: In member function ‘int WrapSmartPointer::operator()(TypeWrapperT&&) [with TypeWrapperT = IntWrapper]’: test-pointer.cpp:23:18: internal compiler error: Segmentation fault 23 | return method(DereferenceSmartPointer::apply); // method(&DereferenceSmartPointer::apply) works |~~^~ 0x1ac4724 internal_error(char const*, ...) ???:0 0x11072d7 make_decl_rtl(tree_node*) ???:0 0x95ad77 expand_call(tree_node*, rtx_def*, int) ???:0 0xab27af expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ???:0 0xa930b4 store_expr(tree_node*, rtx_def*, int, bool, bool) ???:0 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://bugs.archlinux.org/> for instructions. GCC version: g++ (GCC) 12.1.0 (Arch Linux package) System: Linux 5.15.43-1-lts #1 SMP Wed, 25 May 2022 14:08:34 + x86_64 GNU/Linux