All functions declared with si::c-export-fname must be either in
symbols_list.h or have a proclamation so that the compiler knows the
number of arguments that the function takes.
si::coerce-to-vector assumed that the to be coerced object had the
same length as that specified by the type. This lead to segmentation
faults even in safe code, for example in
(coerce '(a b c) '(vector * 4))
(coerce.error.3 test in ansi-tests)
Actually, si::coerce-to-vector had some checks for a correct length
previously, but they did not work correctly and were removed in commit
baaab01841.
This is a dead code which is not used in the compiler. It was meant
for providing entry points from Common Lisp code to ECL functions
written in C, but it was replaced by more robust machinery.
- normalize return-type from NIL to :void, ARRAY and '* in interpreted
dffi implementation -- it is already normalized in sffi
- remove invalid path where argument type was not a valid elementary
FFI type
when it was not c1-defcallback pushed result of add-object to
arg-type-constants and tried to pass the data as opaque
pointers. That said it could never work, because:
1. add-object could return a string (i.e for known symbols expanding
to ECL_SYM) and they were fed as elementary FFI type leading to
errors during compilation by C compiler (invalid enum type)
2. when ecl_make_foreign_data was called to pass opaque objects a
function FFI:SIZE-OF-FOREIGN-TYPE was called which resulted in
error (because return type is not a valid elementary FFI type
what this code path was meant to be)
Moreover we validate both return type and argument types during the
first compiler to fail as early as possible (previously only argument
types were validated early).
- some cosmetic fixes like indentation or redundant PROGN
- move the constant and a function foreign-elt-type-code to the top
- re-align the constant data
- fix the feature reader conditionals (they were misplaced)
- add reader conditionals for complex floats
First one is never bound to T and second one is not referenced at
all. *compilation-time-too* when T was interpreted to evaluate forms
before compiling them (independent of eval-when).
They were silently ignored before in compiled files. The were not
ignored in files which were just loaded.
(define-symbol-macro foo (error "HI"))
foo ; ignored
When we don't know how many arguments an exported function takes, we
can't create a correct declaration for the C function in the .eclh
file. To avoid having too many proclamations, we extract this
information from symbols_list.h for ECL core functions defined in
Lisp.
We also use the *in-all-symbols-functions* variable only for
determining which functions are to be exported during the build of ECL
itself. Otherwise, instead of specifying manually, which Lisp
functions are exported and in the core, we use the information from
symbols_list.h (i.e. we let all_symbols.d initialize all core
functions).
Previously, we assumed that the fixed and variadic arguments of a
variadic function were passed to the function in the same way. The
arm64 calling convention used by iOS breaks this assumption by passing
fixed arguments in registers or on the stack, depending on the
position, while variadic arguments are always passed on the stack.
Solving this problem while still allowing function redefinition at
runtime requires introducing additional dispatch functions. These
dispatch functions take no fixed arguments and pass all their
arguments to the actual function. This dispatch is enabled by passing
-DECL_C_COMPATIBLE_VARIADIC_DISPATCH to the C compiler.
This problem was originally identified and a solution provided by
thewhimer@gmail.com. This commit based on his work with minor
improvements.
C inline information is saved in +default-machine+, which was
previously a constant. However, the value assigned to
+default-machine+ is recomputed during load and compile
time. Technically, assigning a constant a new value which is not eql
to the old one is undefined behaviour in the ANSI standard. What ECL
did was simply to reassign the constant when compiling
cmpc-machine.lsp. However, this meant that the inline information
which was added to +default-machine+ when loading sysfun.lsp was
lost. Thus, all ECL source files compiled after cmpc-machine.lsp were
compiled without inline information. We prevent this by using an
ordinary variable *default-machine* instead of a constant.
When we process required arguments their amount may exceed maximum
number of arguments which are allowed to be passed on C stack. In this
case the remainder is shifted to optionals *but* we have called
next-lcl for all arguments what lead to a situation where all
arguments were passed on the list. Fixes#514.
The pipe from which we read the output of the C compiler could fill up
when a large number of warnings were printed leading to a deadlock
because we waited for the C compiler to finish before reading the
output.
Many parts of the source code were bent backward to support builds
without long floats which are always present given we depend expect
c99 compiler.
The corresponding C macros (ECL_LONG_FLOAT) and the *feature*
entry (:long-float) are marked as deprecated in the documentation.
For functions without returned value we did return cl_object value0
which was not initialized. That could lead to segmentation faults if
we have used result of calling a function defined as such location.
SFFI definition like this:
(ffi:def-function ("my_test_function3" sffi-test-3)
((x :float) (y :double))
:returning :void)
was previously compiled to
/* function definition for SFFI-TEST-3 */
/* optimize speed 3, debug 0, space 0, safety 2 */
static cl_object L6sffi_test_3(cl_object v1x, cl_object v2y)
{
cl_object env0 = ECL_NIL;
const cl_env_ptr cl_env_copy = ecl_process_env();
cl_object value0;
ecl_cs_check(cl_env_copy,value0);
{
TTL:
my_test_function3(ecl_to_float(v1x),ecl_to_double(v2y));
cl_env_copy->nvalues = 0;
return value0;
}
}
and now it is compiled to
/* function definition for SFFI-TEST-3 */
/* optimize speed 3, debug 0, space 0, safety 2 */
static cl_object L6sffi_test_3(cl_object v1x, cl_object v2y)
{
cl_object env0 = ECL_NIL;
const cl_env_ptr cl_env_copy = ecl_process_env();
cl_object value0;
ecl_cs_check(cl_env_copy,value0);
{
TTL:
my_test_function3(ecl_to_float(v1x),ecl_to_double(v2y));
value0 = ECL_NIL;
cl_env_copy->nvalues = 0;
return value0;
}
}
void functions are treated the same as when *destionation* is 'RETURN
in cmpmulti.lsp.
- add ffi implementation for long-float
- add ffi implementation for (complex float) types
- add compiler optimizations and definitions for complex float
We do not add c?float common constants (long-float i.e has optimizer
for 0.0 and -0.0), because we don't know if they are common at all and
if we think about it each would have four entries counting signed
zeros).
Also add informative comment about global-entries.
What has changed:
- new types si:complex-float, si:complex-single-float,
si:complex-double-float and si:complex-long-float
- new builtin classes long-float (for completness) and
si:complex-float
- new internal function si:complex-float and si:complex-float-p for
constructing complex floats (both arguments must be of the same
float type) and a type predicate
- printer for new types (right now it conses, see below)
- a new feature :complex-float
- a new type is recognized as a type disjoint of complex and real
- cleanup: +built-in-type-list+: remove some redundancy
For instance instread of saying
(real (or integer single-float double-float ratio))
We say
(real (or integer float ratio))
etc.
Flaws which will be fixed in upcoming commits:
- complex-float hierarchy is independent of the complex hierarchy
- ecl_make_complex_float could be replaced by _ecl_make_complex_*float
- write_complex_float allocates new objects for printing
- write_complex_float does print unreadable object
- math dispatchers doesn't recognize the object
Testing things out:
> (si:complex-float 0.0d0 0.0d0)
; #<CF(0.0d0 0.0d0)>
> (si:complex-float 0.0d0 0.0s0) ; signals type error
> (+ (si:complex-float 0.0d0 0.0d0) 1) ; signals type error
lisp runtime: make si_complex-float a subtype of a number.
TYPE= is only used from cmpopt's typep compiler macro which optimizes
atomic complex types by other means. Compound complex types are
handled differently for subtypep and typep (the first relies on
upgraded type and the second relies on the actual types), so we can't
rely in this case on SAFE-CANONICAL-TYPE.
This behaviour makes more sense, since the ANSI standard mandates
that disassemble should compile an interpreted function before
displaying the output (our own documentation even says so).
Also fixes disassemble for closures.
