many tests error out with:
"64 bit integers are not supported on this platform and with this C compiler: SINT64"
there should be a feature test for that
we already have a word-size=64 feature (enabled when WIDE_HARD is defined), so
#+word-size=64 is enough to fix this specific failure (since WIDE_HARD ==> HAVE_LONG_LONG_INT).
however, there are situations when words are 32-bit, but FFI can handle 64-bit ints.
Should we add an FFI-64BIT feature?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<http://article.gmane.org/gmane.lisp.clisp.devel/21011>
from Jorg:
I dislike #+features, because that causes .fas file to cease to be shareable among machines. There could be a huge, otherwise portable .fas file, which causes mysterious failures for no other reason that a single #+64bit in the source, whereas others, like #+clisp of course cause no harm.
For the needs ffi.tst, (ignore-errors (parse-c-type 'ffi:uint64)) could be enough? Or another instance of
(ignore-errors
(def-call-out "ffi_identity" ... uint64)
(funcall pseudo-identity 0))
This raises the question about
a) whether the FFI:UINT64 should exist in all cases
I say yes because it causes package issues otherwise.
b) whether parse-c-type accepts ffi:uint64 even though the C does not support it.
No seems resonable. However:
What about cross compilation? Shouldn't I be able to compile a .fas file on one machine and execute it on another one?
I'd say yes. So errors should only appear at run-time, trying to invoke the function??
There could be compiler constant folding issues with .fas files. I remember one optimization that turns (parse-c-type 'ffi:uint) into 'uint. So the runtime must be prepared to get called with an uint46 internal-c-type even ffcall or the C compiler does not support it, and error out (I'm sure it does).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I decided to disable the 64-bit tests on non-WIDE_HARD platforms (so that the tests pass on all platforms)
but not to introduce a special conditional so that cross compilation is preserved.
you have 2 weeks to complain here, after that the bug will be closed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>I decided to disable the 64-bit tests on non-WIDE_HARD platforms
>(so that the tests pass on all platforms)
If I understood right, you don't test uint64 on the typical 32bit Linux machine anymore?
I think this is a bad move. Running tests is important -- everywhere.
Why not use something like
(devar available (ignore-errors ...detector...))
available
(if available ...testx... #| else precomputed value |# 64)
64
(if available ...testy... T)
T
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
we already have a word-size=64 feature (enabled when WIDE_HARD is defined), so
#+word-size=64 is enough to fix this specific failure (since WIDE_HARD ==> HAVE_LONG_LONG_INT).
however, there are situations when words are 32-bit, but FFI can handle 64-bit ints.
Should we add an FFI-64BIT feature?
<http://article.gmane.org/gmane.lisp.clisp.devel/21011>
from Jorg:
I dislike #+features, because that causes .fas file to cease to be shareable among machines. There could be a huge, otherwise portable .fas file, which causes mysterious failures for no other reason that a single #+64bit in the source, whereas others, like #+clisp of course cause no harm.
For the needs ffi.tst, (ignore-errors (parse-c-type 'ffi:uint64)) could be enough? Or another instance of
(ignore-errors
(def-call-out "ffi_identity" ... uint64)
(funcall pseudo-identity 0))
This raises the question about
a) whether the FFI:UINT64 should exist in all cases
I say yes because it causes package issues otherwise.
b) whether parse-c-type accepts ffi:uint64 even though the C does not support it.
No seems resonable. However:
What about cross compilation? Shouldn't I be able to compile a .fas file on one machine and execute it on another one?
I'd say yes. So errors should only appear at run-time, trying to invoke the function??
There could be compiler constant folding issues with .fas files. I remember one optimization that turns (parse-c-type 'ffi:uint) into 'uint. So the runtime must be prepared to get called with an uint46 internal-c-type even ffcall or the C compiler does not support it, and error out (I'm sure it does).
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).
I decided to disable the 64-bit tests on non-WIDE_HARD platforms (so that the tests pass on all platforms)
but not to introduce a special conditional so that cross compilation is preserved.
you have 2 weeks to complain here, after that the bug will be closed.
>I decided to disable the 64-bit tests on non-WIDE_HARD platforms
>(so that the tests pass on all platforms)
If I understood right, you don't test uint64 on the typical 32bit Linux machine anymore?
I think this is a bad move. Running tests is important -- everywhere.
Why not use something like
(devar available (ignore-errors ...detector...))
available
(if available ...testx... #| else precomputed value |# 64)
64
(if available ...testy... T)
T
feel free to propose the "...detector..." code
I can no longer reproduce this on woe32 (somehow HAVE_LONG_LONG_INT is now defined) so I don't know what platforms need this.
reverting the patch.