#296 ffcall HAVE_LONG_LONG vs. LONGLONG
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
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)
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.
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.
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).
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! :-(