In case that someone wants to store the definition when compiling the file, we
need to make sure that the compiler does not error if it has unreadable objects.
cmp: check that the type of init-forms for optional and keyword arguments matches their proclaimed types
See merge request embeddable-common-lisp/ecl!316
These tests are not guaranteed to succeed but are still useful
to check for regressions for those configurations for which
thread synchronization primitives are interrupt safe.
We give values between 0 and 255, so the character arrays have to be
unsigned but we are interpreting them as ordinary char arrays
later (which may be signed), so we have to put in an explicit cast.
These are valid in type declarations but must not be passed on as
arguments to typep.
Moreover, we were sometimes incorrectly simplifying code like
(typep x (function ...))
to (functionp x) in the native compiler.
The problem encountered in 3f64e2e88b
affects not only the case of a logarithm where one argument is a
rational and the other a long or double float, but also cases where
both arguments are floating point numbers of different lengths.
For (log x y) where one of the two arguments is a double or long float
and the other a rational number, defining (log x y) as (/ (log y) (log
x)) is imprecise since intermediate single float results will be used
for the rational argument. Prevent this by computing the logarithm of
the rational to the same precision as that of the other argument.
Fixes#688.
- directly construct the complex result for negative real numbers
instead of calling ecl_log1_complex_inner(x, ecl_make_fixnum(0))
- get rid of unnecessary double calls to ecl_to_float in ecl_log1_simple
- prevent floating point overflow for negative bignums in the same way
as for positive ones
For functions already compiled and loaded, we simply check if the
definition is a closure. For functions defined in the same file, we
don't store their definition in the compiler environment but instead
use *global-funs*. The advantage is that this directly allows us to
determine whether a function is a closure or not and we don't have to
run the first compiler pass again each time we inline the function.
This commit also fixes some minor issues with the inline policy,
described in detail as follows:
1. The inline policy differed subtly between `proclaim` and `declaim`.
If a file like
(eval-when (:compile-toplevel)
(proclaim '(inline f)))
(defun f ...)
was compiled (but not loaded), subsequent compilations would inline
`f` but for
(declaim (inline f))
(defun f ...)
the function `f` would only get inlined if the file was compiled _and_
loaded. We now use the latter approach for both cases. Thus, calling
`compile-file` without `load` has no side-effects regarding whether
functions are inlined or not.
2. We did not distinguish between functions which were declared inline
at a global versus local level such that e.g. in
(locally
(declare (inline f))
(defun f ...))
the function f would get inlined outside the scope of the `locally`
form. This is changed now such that local inline declarations only
apply to the scope in which they are made.
3. Inline declarations were made by expanding into statements like
(eval-when (:compile-toplevel)
(c::declare-inline ...))
during the macroexpansion of `defun`. However this only works if the
`defun` appears at the toplevel and hence in code like
(declaim (inline f))
(let (...)
(defun f ...))
the function `f` could not get inlined later on in the same file. This
is fixed now by calling the code which should run during compilation
directly when macro expanding defun.
Due to rounding issues the exponent can be different than what we
guessed. For example in the following only one digit should appear
before the decimal point such that
(format nil "~,1e" 9.9) => 9.9e+0
is correct but
(format nil "~,1e" 9.9) => 10.0e+0
is incorrect, has to be 1.0e+1.
