Hi Peter, Sorry for the late reply, and thanks for investigating.
I reproduced the bug on GNU/Linux with Clang 3.1. Peter Teeson <peter.tee...@me.com> skribis: > I think the reason that we get this error is that the "a" argument is > declared to be only 8 bits wide > but is passed in as -1 which is correctly represented as 0xFFFFFFFF > > However an 8-bit representation is 0xFF which is only 255. This is part of the issue. Consider this example: --8<---------------cut here---------------start------------->8--- #include <stdint.h> int64_t test_sum (int8_t a, int64_t b) { return a + b; } --8<---------------cut here---------------end--------------->8--- When compiled with GCC 4.6, the assembly is: --8<---------------cut here---------------start------------->8--- test_sum: .LFB0: .cfi_startproc movsbq %dil, %rdi leaq (%rdi,%rsi), %rax ret .cfi_endproc --8<---------------cut here---------------end--------------->8--- With Clang 3.1, it is: --8<---------------cut here---------------start------------->8--- test_sum: # @test_sum .cfi_startproc # BB#0: movslq %edi, %rax addq %rsi, %rax ret --8<---------------cut here---------------end--------------->8--- The ‘movsbq’ emitted by GCC arranges to keep only the 8 LSBs. Clang does no such thing, thus keeping all the bits of the first operand in the addition. I looked at Section 3.2.3 (“Parameter Passing”) of the SysV ABI x86_64 PS but couldn’t find any evidence as to what the correct behavior is. However, on the caller side, both compilers emit the same code. This program: --8<---------------cut here---------------start------------->8--- #include <stdint.h> extern int64_t test_sum (int8_t a, int64_t b); int64_t foo (void) { return test_sum (-1, 123132); } --8<---------------cut here---------------end--------------->8--- leads to the following assembly with both compilers: --8<---------------cut here---------------start------------->8--- foo: # @foo .cfi_startproc movl $-1, %edi movl $123132, %esi # imm = 0x1E0FC jmp test_sum # TAILCALL --8<---------------cut here---------------end--------------->8--- (And as we’ve seen, libffi does the same.) So that seems to indicate that the callee code generated by Clang is incorrect as it fails to discard the 24 MSBs of its first argument. Could you report it as a Clang/LLVM bug (keeping 13...@debbugs.gnu.org Cc’d)? Thanks! Ludo’.