Am Di., 21. Juli 2026 um 02:06 Uhr schrieb Trevor Gross <[email protected]>: > > On Tue Jul 7, 2026 at 10:37 AM CDT, Jonathan Yong wrote: > > On 6/29/26 19:50, Oleg Tolmatcev wrote: > >> GCC could return __int128 values in SSE (%xmm0) on Windows x64 instead > >> of following the MS x64 ABI. Root cause: return classification allowed > >> 128-bit integer-like scalars to be treated as direct register returns. > >> This patch updates the Windows x64 return-classification and codegen to > >> treat int128 as an indirect return (caller-provided slot passed as first > >> argument, pointer returned in RAX). > >> > > > > Ping, reviewers? > > Coming here via the corresponding LLVM updates. I've done a lot of > digging on this topic and it seems like the general consensus is that > the ABI after this change is likely preferable to using a SSE register. > I had a similar patch ready at one point but decided not to send it > because of how I weighed the breakage (I am glad somebody else did). > > I don't think the commit message is especially accurate, though, taking > some inspiration from LH's note at [1]. It says "following the MS x64 > ABI" but there is no ABI for `__int128`. At best, we're reading between > the lines trying to figure out a reasonable extension ABI, and arguably > there is no bug in the first place because there is nothing to match. > > Could either of you confirm what happens with this patch when `-mno-sse` > is passed? Currently it looks like a 2-register return [2], it would be > good if that's changed/tested here as well. (Note also that, as far as I > know, tests are completely broken on Windows hosts [3].)
LH already answered, so I will only comment on the tests. I also encountered this problem after msys2-runtime's updgrade https://github.com/msys2/msys2-runtime/issues/349. I don't think the problem has anything to do with GCC. It looks like a Cygwin bug in in the pcon implementation. That PR can probably be closed. > > - Trevor > > --- > > P.S. I did some codebase archeology at one point and got the impression > that the xmm0 return came to be because fallthrough, rather than > something intentional. Couldn't really confirm this but it might explain > the status quo. > > [1]: > https://inbox.sourceware.org/gcc-patches/[email protected]/t/#u > [2]: https://gcc.godbolt.org/z/6v3jGxMrb > [3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121943
