#296 ffcall HAVE_LONG_LONG vs. LONGLONG

build problems
closed-accepted
ffi (23)
6
2006-02-02
2005-12-19
No

Hi,

I noticed that while avcall/tests.c contains 2 long
long tests
(controlled by #ifdef HAVE_LONGLONG), the actual run of
minitests on
i686-pc-linux-gnu did not use them
(build-gcc/avcall/minitests.out).
Maybe HAVE_LONGLONG is not defined for AVCALL?? This
starts to look
like a bug that I should report to ffcall.sf.net
-- Oops, wasn't ffcall once a distinct package on SF?!?
Yet the entries I found on fsf.org and freshmeat.net
all redirect to Bruno, without mention of a bugtracker.
If ffcall is not hosted within clisp, then I suggest to
add the category "ffcall" to the clisp/sf bugtracker.

snippet of minitests.out
ushort f(char,double,char,double):('a',0.2,'€',0.4)->65506
ushort f(char,double,char,double):('a',0.2,'€',0.4)->65506
void*
f(void*,double*,char*,Int*):(0x804cbf6,0x804cc68,0x804b4d0,0x804cb60)->0x804cc69
void*
f(void*,double*,char*,Int*):(0x804cbf6,0x804cc68,0x804b4d0,0x804cb60)->0x804cc69

The longlong tests should have appeared between the two.

The bug is as follows: avcall/config.log says
#define HAVE_LONG_LONG 1
while tests.c contains
#ifdef HAVE_LONGLONG

As a result, the 64bit functionality of ffcall goes
untested.
CLISP's own build-gcc/config.log contains
| #define HAVE_LONG_LONG 1
| #define HAVE_LONGLONG
but it's not yet used at the time ffcall is built.

Note that clisp does not use av_longlong (available in
avcall.h). I
suppose CLISP's code was not revised when ffcall
defined it.

Regards,
Jörg Höhle

Discussion

  • Sam Steingold

    Sam Steingold - 2005-12-19
    • labels: --> ffi
     
  • Jörg Höhle

    Jörg Höhle - 2006-01-03

    Logged In: YES
    user_id=377168

    I found out that HAVE_LONG_LONG seems to be the general name
    (as found in the various longlong.m4 files by Paul Eggert on
    my system). (CLISP uses HAVE_LONGLONG)

    I prefer Bruno makes changes in ffcall as the maintainer,
    since several files are affected and I don't know for sure
    which of these are source and which generated.

    It may affect sparc code generation:
    /* temporary storage, used to split doubles into two words */
    avcall.h.in:319:#if defined(__sparc__) &&
    !defined(__sparc64__) && defined(HAVE_LONGLONG)

     
  • Jörg Höhle

    Jörg Höhle - 2006-01-31

    Logged In: YES
    user_id=377168

    In CLISP, HAVE_LONGLONG means there's some type with width
    64 bits, either just long (sparc64 etc.), or long long, or
    __int64 with MS-VC.

    What's the meaning in ffcall?
    "long long" or
    "whatever type name on the current platform for such a thing"?
    What should av/va_[start]_longlong() do?

    How do the compilers pass long long (or __int64)? --
    obviously not as a struct, otherwise Pascal's and CFFI's
    tests would not fail.

    After ffcall fixes this issue, I'll update my current
    patches to foreign.d, if needed, then clisp will hopefully
    have a working 64bit ffi on all platforms again.

     
  • Jörg Höhle

    Jörg Höhle - 2006-02-02

    Logged In: YES
    user_id=377168

    After talking with Bruno Haible, I
    Changed all HAVE_LONGLONG inside ffcall to HAVE_LONG_LONG.
    All tests pass on i686 Linux with gcc-4.0 and now include
    the long long tests!
    E.g. some minitests.out:
    ushort f(char,double,char,double):('a',0.2,'€',0.4)->65506
    ushort f(char,double,char,double):('a',0.2,'€',0.4)->65506
    long long f(float,long
    long,int):(1.4,0x35c6f707fffffffa,0xe)->0x35c6f70800000009
    long long f(float,long
    long,int):(1.4,0x35c6f707fffffffa,0xe)->0x35c6f70800000009
    Int f(Int,Int,Int):({1},{2},{3})->{6}
    Int f(Int,Int,Int):({1},{2},{3})->{6}

    Bruno also told me that other types (e.g. MS-VC's __int64)
    are not supported. HAVE_LONG_LONG is for long long, nothing
    else.

     
  • Jörg Höhle

    Jörg Höhle - 2006-02-02

    Logged In: YES
    user_id=377168

    thank you for your bug report.
    the bug has been fixed in the CVS tree.
    you can either wait for the next release (recommended)
    or check out the current CVS tree (see http://clisp.cons.org\)
    and build CLISP from the sources (be advised that between
    releases the CVS tree is very unstable and may not even build
    on your platform).

     
  • Jörg Höhle

    Jörg Höhle - 2006-02-02
    • status: open --> closed-accepted
     
  • Jörg Höhle

    Jörg Höhle - 2006-02-03

    Logged In: YES
    user_id=377168

    The change had another beneficial effect. Yesterday I
    puzzled why my old MS-VC6 build did not appear to support
    ffi:uint64.

    It's only in the evening that I realized that avcall.h
    contains #undef HAVE_LONGLONG.
    Thus for years, MS-VC must have been compiled this way, and
    nobody complained! :-(

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks