[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13342: [PARTIALLY SOLVED] bug#13342: Errors trying to build Guile 2.

From: Ludovic Courtès
Subject: bug#13342: [PARTIALLY SOLVED] bug#13342: Errors trying to build Guile 2.0.7
Date: Mon, 28 Jan 2013 13:56:43 +0100
User-agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux)

retitle 13342 Clang, the FFI, and 8-bit signed integers
merge 13342 13386


Mark H Weaver <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:


>> 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.
> I read the same section, and although it is not as clear as I'd prefer,
> my interpretation is that the caller is responsible for sign-extending
> signed chars to ints.

What exactly in that section makes you think so?

> Clang strictly requires callers to sign-extend, whereas GCC is tolerant
> of callers who fail to do so.  IMO, both behaviors are permitted by the
> ABI.
> The problem is that libffi does *not* sign-extend arguments passed in
> registers when making calls, which is IMO a bug that has gone (mostly)
> unnoticed because of the tolerance and ubiquity of GCC.

Oh, I see.

>> However, on the caller side, both compilers emit the same code.  This
>> program:
>> #include <stdint.h>
>> extern int64_t test_sum (int8_t a, int64_t b);
>> int64_t
>> foo (void)
>> {
>>   return test_sum (-1, 123132);
>> }
>> leads to the following assembly with both compilers:
>> foo:                                    # @foo
>>      .cfi_startproc
>>      movl    $-1, %edi
>>      movl    $123132, %esi           # imm = 0x1E0FC
>>      jmp     test_sum                # TAILCALL
>> (And as we’ve seen, libffi does the same.)
> No, libffi does *not* do the same.  Take a look at the relevant code:
>   https://github.com/atgreen/libffi/blob/master/src/x86/ffi64.c#L488



> In summary, I think this is a bug in libffi.
> Note that it has already been reported that the libffi testsuite shows
> many failures on OS X Lion, and the failures appear to be related to
> this precise issue:

Note that it’s not just Darwin: I tested with Clang on GNU/Linux.

>   http://sourceware.org/ml/libffi-discuss/2012/msg00162.html
> The libffi maintainer wrote "I'm going to chalk this up to compiler
> bugs", based on his observation that the tests worked properly when
> compiled with -O0.  I think it's time to raise this issue again on the
> libffi-discuss mailing list.

Would you like to email them?

Anyway, thanks for the thorough investigation!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]