From: SourceForge.net <no...@so...> - 2006-01-31 13:18:51
|
Bugs item #1385013, was opened at 2005-12-19 10:11 Message generated for change (Comment added) made by hoehle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1385013&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ffi Group: build problems Status: Open Resolution: None Priority: 6 Submitted By: Jörg Höhle (hoehle) Assigned to: Bruno Haible (haible) Summary: ffcall HAVE_LONG_LONG vs. LONGLONG Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Jörg Höhle (hoehle) Date: 2006-01-31 14:18 Message: 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. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-01-03 13:22 Message: 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) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1385013&group_id=1355 |