Not all processors will signal floating point exceptions even when
told so, for example the Raspberry Pi as Dave Richards pointed out on
the ecl-devel mailing list.
Using isnan and isfinite to check for floating point exceptions
doesn't work when we want floats to be able to have infinity or NaN as
values, thus this option was removed with commit
5f71f728a3. However, we can still use
fetestexcept to explicitly check if floating point exceptions occurred
even when we can't use the feenableexcept/SIGFPE signal delivery
mechanism.
Previously, we had something like this in the
ECL_MATHERR_TEST/ECL_MATHERR_CLEAR macros, but this was not used
consistently in our codebase (the ECL_MATHERR_TEST macro was missing
in many places). Instead of error-prone testing at every point of
computation, we call fetestexcept in DO_DETECT_FPE when creating a new
float/complex float. In order to avoid having to do this twice, the
DO_DETECT_FPE2 macro is introduced.
A minor disadvantage of this strategy is that floating point
exceptions may be signaled later than they occurred.
The gmp manual (https://gmplib.org/manual/Custom-Allocation.html) states
> GMP may use allocated blocks to hold pointers to other allocated
blocks. This will limit the assumptions a conservative garbage
collection scheme can make.
Thus we can't use ecl_alloc_atomic. We could just use ecl_alloc
instead, however our implementation is already structured in such a
way that it is sufficient to use ecl_alloc_uncollectable. The reason
for that is that currently all bignums except those in the bignum
registers in the thread local environment are allocated as compact
objects so that we only need to call mpz_clear for the few non-compact
objects in the bignum registers.
See also commits 7b536161 and bd48b859.
Fixes#485.
Remove flag AI_V4MAPPED which takes effect only for AF_INET6
family. Currently we do not work at all with ipv6, hence this flag is
a no-op. Moreover Android has no definition for this flag. See !172.
Fix contributed by Polos Ruetz. Closes!172.
Previously: unconditionally use the size from ECL_OPT_C_STACK_SIZE if
it is larger than the OS provided value and if possible resize the
stack at runtime.
Now: Use ECL_OPT_C_STACK_SIZE if provided. Otherwise, use a) the OS
provided value if we can resize the stack at runtime (for Unix) or b)
the new build option ECL_DEFAULT_C_STACK_SIZE (1 MB) if we can set the
stack size at link time (for Windows).
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
This is more robust against changes in the abi support in libffi.
We also remove unused struct and enum type definitions (left over from
our own dynamic ffi implementation?).
ecl_cs_set_org and cs_set_size had several problems:
-the size of the stack was estimated to be 1/2 of the actual value,
which could lead to wrong stack overflow errors. In particular, we
cannot assume that the stack pointer will always start at the stack
origin and increase/decrease linearly (counterexamples could
include callbacks from other threads).
-despite its name, cs_set_size did not actually set the stack size
even on systems where this is possible at runtime.
-there were several magic numbers used.
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.
Various macros created lambda-blocks with names that could be equal to
names of unrelated functions. The compiler would then try to apply
proclamations for these functions to the lambda-block. Prevent this by
expanding to a (lambda (...) (block name ...)) instead
of (lambda-block name (...) ...).
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.
