https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942
James Y Knight <foom at fuhm dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |foom at fuhm dot net
--- Comment #10 from James Y Knight <foom at fuhm dot net> ---
Well, the ABI doc doesn't appear to say anything about this still.
GCC as of 5.1 seems to still do sign/zero extension of 8/16-bit arguments to
32-bit on the callee side. Clang does not. Both do extension of 32-bit
arguments to 64-bit on the callee side.
Both sign/zero-extend 8/16-bit values to 32-bits, and do /not/ truncate 64-bit
values to 32-bit on the caller side.
So it looks like GCC could still generate more optimal code by taking advantage
of the "de-facto" ABI that lets you assume 32-bit sign/zero-extension has
happened on arguments.
But it'd also be real nice for this all to be actually documented, so there's
something to point people to. :)
BTW: This undocumentedness came up recently with an optimizer change in clang:
libjpeg-turbo has some assembly code which was using the full 64-bit value of
an argument register, assuming the upper bits would be zeroed, while on the C
side, the function was declared as taking an "int". The upper bits are thus
left undefined (as is correct, per the unwritten ABI rules), which broke the
asm.
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/20
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20150907/138253.html
