[ clisp-Bugs-1385013 ] ffcall HAVE_LONG_LONG vs. LONGLONG

[SourceForge.net <no...@so...>]

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-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