在 2026-8-9 22:43, Oleg Tolmatcev 写道:
Libgcc helper libcalls such as __udivti3 still use the historical TImode direct-return convention. Preserve that convention when TARGET_RETURN_IN_MEMORY is queried for a libcall so the caller's expectation continues to match libgcc on x86_64-w64-mingw32.gcc/ChangeLog: PR target/78799 * config/i386/i386.cc (ix86_return_in_memory): Keep TImode libcalls on the direct-return convention. * testsuite/gcc.target/i386/pr78799-2.c: New test. Signed-off-by: Oleg Tolmatcev <[email protected]> --- gcc/config/i386/i386.cc | 8 ++++++- gcc/testsuite/gcc.target/i386/pr78799-2.c | 28 +++++++++++++++++++++++ 2 files changed, 35 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/gcc.target/i386/pr78799-2.c
I have two questions about this change:First is that `__udivti3` seems defined in libgcc2.c and returns `__int128` in memory, so this change would result in a mismatch of how the value is returned, wouldn't it?
Second is that the commit message says 'the caller's expectation continues to match libgcc on x86_64-w64-mingw32', but for GCC 16- (before e63a873f1df7493b8b657acafb451bf40166044e) the value is returned in XMM0. Does this change expect the result in XMM0 or RDX:RAX? If the result should go into RDX:RAX then it's still an ABI break with GCC 16 and therefore makes less sense.
-- Best regards, LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
