For empty structs, the size was off by one. While this did not affect
structs that were created directly with the structure constructor, for
structs that were externalized with MAKE-LOAD-FORM-SAVING-SLOTS
instances which were one element too large were created.
The pattern in the long form of the define-method-combination may contain * as
a list element meaning "any" qualifier. For example:
(define-method-combination foo ()
((bar (:xxx * :yyy)))
...)
In this case qualifiers `:xxx 3 :yyy' and `:xxx :zzz :yyy' will match.
The comment mentioned that aux variables (the sixth value) are returned the
same way as requireds, optionals and keywords however factually that was not
the case - the number of variables was not the first element of the list. This
commit updates the function and all its callers.
Previously for example (prin1 1.0e-8) would result in 1.e-8. However,
the ANSI standard (see CLHS section 22.1.3.1.3) specifies that there
has to be at least one digit after the decimal point therefore we now
print 1.0e-8.
Since our ancient LGPL licensed copy of libgmp only knows about
PowerPC apple devices, build it using the fallback plain C
implementation as on x86.
Closes#689.
Autoconf detects that the system function is present but compilation
fails with
error: 'system' is unavailable: not available on iOS
Therefore we manually disable this function for iOS.
Closes#691.
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
Previously, we unconditionally created closures when a lambda form was
encountered in a non-empty lexical environment. Now we check first if
something from the enclosing environment is actually used in the
function.
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.
