https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942
--- Comment #13 from Florian Weimer <fw at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #12) > (In reply to Florian Weimer from comment #11) > > The ABI document was updated: > > > > Clarify the unspecified nature of excess bits in INTEGER type arguments > > <https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/ > > e1ce098331da5dbd66e1ffc74162380bcc213236> > > > > The ABI did not previously say that the caller needs to sign-extended or > > zero-extend, which means that the callee has to extend. As far as I can see, > > both GCC and Clang generate code in some cases that assumes the callee > > extends. > > I'm not aware of any cases where GCC does assume that on x86_64. > As mentioned in #c0, often we extend both on the caller and callee side, on > the caller side it is just our problem doing something that doesn't have to > be done (but guess often is faster that way). Not sure if I understand. What about this? void f (int); void g (long int x) { return f (x); } It gives me (with -fno-asynchronous-unwind-tables -O2): .file "u.c" .text .p2align 4 .globl g .type g, @function g: jmp f .size g, .-g .ident "GCC: (GNU) 14.2.1 20240912 (Red Hat 14.2.1-3)" .section .note.GNU-stack,"",@progbits I think this means that the implementation of f must extend (if needed) because g did not sign-extend or zero-extend.
