ср, 12 авг. 2026 г. в 09:44, LIU Hao <[email protected]>: > > 在 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.
Thanks for the review. Good catch. It is indeed unnecessary and I am withdrawing it.My tests were crashing because of a mismatch between GCC 17 and libgcc from GCC 16 and my analysis was wrong. Thanks again for the review. Oleg
