https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Florian Weimer from comment #13) > (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. If I read your psABI change right, this case is just fine, the upper 32 bits of %rdi upon entry to f are unspecified, so no extension is needed. Where you need to extend is void h (long int x); void i (int x) { return h (x); } and gcc does that.
