The compiler was coercing base strings to extended strings when
encountering them as literal objects in compiled files. According to
CLHS 3.2.4.2.2, we need to preserve the actual element type (after
upgrading) of arrays during compilation. For ECL, the actual array
element type of a base-string is base-char and therefore we can't
change this to an extended string.
Actually fixing this requires some work since we use the reader to
store a printed representation of the string in the compiled file. The
reader string syntax always returns an extended string (There is a
comment in the code which claims that this is implied by CLHS 2.4.5. I
am not quite sure if that is really true but for backwards
compatibility I don't want to change this). We thus introduce a new
syntax #"..." for base strings which is used when reading objects from
compiled files. To prevent the new syntax from leaking outside of this
context, we also introduce a new readtable.
We can't pass compound function types (i.e. function types which
include argument and return types) to TYPEP. At some places, this was
already handled but not everywhere. A new function CMP-TYPEP is
introduced to handle this. At any place where a user-supplied type is
checked at compile time, we need to use CMP-TYPEP instead of TYPEP.
Dead code eliminiation often happens for automatically generated code,
so this leads to many false positives for code that doesn't have any
style issues.
Moreover, the combination of compiler-note and style-warning is
handled badly by asdf. By default, we don't display compiler-notes but
asdf catches style-warnings to display a notice that a style-warning
has been emitted which is confusing since no warning has been printed.
We need to save and restore the reference to the current function in
the environment before calling any finalizers. Otherwise, it can
happen that this is overwritten after we have set it but before
actually calling the function. This can lead to all sorts of issues
because closure environments are wrong or variadic dispatch doesn't
work correctly.
The bug appeared intermittently when compiling maxima from a version
of ECL compiled with CFLAGS="-DECL_C_COMPATIBLE_VARIADIC_DISPATCH" and
--disable-threads.
There were a number of bugs here:
- REAL was returned even for complex exponents
- The special case of exponent=0 wasn't handled correctly
- In some cases, EXPT could return integer or rational results but the
type propagator would always assume that coercion to floating point
was happening.
Examples of the bug
(expt -1.4d0 #C(1 2)) -> #C(-0.0020444484 -0.0016295447)
(expt #C(1.0 3.0) 0.0d0) -> #C(1.0 0.0)
These return a (complex single-float), should be (complex double-float).
The code incorrectly assumed that the numbers associated to the types
tx and ty were ordered such that long floats and complex long floats
have higher numbers than double floats and complex double floats.
We include captured functions, blocks and variables along with local
variables. This fixes#799.
Moreover DECODE-IHS-ENV is deperacated and more DWIM:
- calls DECODE-IHS-LOCALS for old arguments
- appends DECODE-IHS-LOCALS and DECODE-IHS-LEXENV for ihs index
DECODE-IHS-LOCALS and DECODE-IHS-LEXENV are responsible for decoding appropriate
environments.
We deprecate the function si_ihs_env in favor of more explicit si_ihs_lex and
si_ihs_lcl, but the former is left for backward compatibility with SLIME/SLYNK
because they call it to query the environment to add locals to the backtrace.
Since ~recently we store local variables in the bytevm on the stack. Also, the
native comipler under specified debug options, stores locals in ihs, but it has
nothing to do with the lexical environment. So it feels justified to push both
to a separate field.
It may seem like this proclamation is invalid sincd !346, but the divergence
happens much earlier. 8c0314022c introduces a
feature where c-compiled code can also add debug information, and in that case
the environment is a vector, so the proclamation back then should be:
(proclamation si:ihs-env (si::index) (or list vector))
Later when we've changed the representation, it should be changed to
(proclamation si:ihs-env (si::index) (or null vector))
Where NULL denotes "no lexical environment".
(DEFCONFIG *LD-SHARED-FLAGS*) was called without a value when dlopen was not
defined, that lead to error when destructuring. We put there "" instead now.
Previously, calling COMPILE during cross compilation always failed due
to trying to load a shared object compiled for the wrong architecture.
We now temporarily switch back to the host configuration, compile and
load our shared object, and then go on with the target config.
Cross compilation of ECL itself:
- The windres program comes with the usual cross compilation target
prefixes, use AC_CHECK_TOOL to select the right one.
- For c::update-compiler-features, we need to check the features of the
host system instead of the target because that determines the
executable prefix of the ecl_min stub.
Cross compilation of user code: We just have to replace some read time
conditionals by runtime checks.
Further notes on Windows cross compilation using mingw:
- Our old copy of libgmp doesn't work, one needs to update that before
compiling.
- ASDF fails to compile unless XDG_CACHE_HOME is set (it tries and
fails to find a Windows cache directory if XDG_CACHE_HOME is empty).
- The `windres` program may be located in a separate package from the
mingw compiler. On debian, I had to install binutils-mingw-w64 and
gcc-mingw-w64.
This is a bit tricky to solve since UPGRADED-COMPLEX-PART-TYPE and
SUBTYPEP behave differently depending on whether we have complex float
support or not and the behaviour is a special case compared to other
types due to the upgrading of part types that is happening.
What we do now is to add a custom declaration in the environment and
select the behaviour based on a runtime check.
This allows us to switch out the proclamations when cross-compiling so
that target specific functions are declared correctly.
This was a problem for cross compilation with mismatching thread
support, so we can now allow that.
Due to the recent introduction of cross compilation features,
*cmp-env* has to contain type information throughout the entire
compilation (not only while we are compiling a form) so that (typep x
type *cmp-env*) works correctly. Therefore, we can't set *cmp-env* to
nil initially as we did previously. Instead, we set *cmp-env*
to *cmp-env-root* initially.
We start a remote ECL host and replace COMPILE-FILE and COMPILE by a
stub which shells out compile commands to this remote ECL. Moreover, a
few commands defining types, special variables and proclamations are
mirrored in the remote ECL as well. This of course is not a complete
synchronization mechanism and thus the state of the remote ECL will
not be 100% the same as that of the host which means that the COMPILE
stub is not an entirely correct implementation of the ANSI standard.
But it works well enough to run the test suite which is all we need.
A host compiler without complex float support still needs to be able
to emit C instructions for complex float. In this case, the host
doesn't define si::complex-{single/double/long}-float types, so we
need to replace those by types which all variants of ECL understand.
Moreover, functions for emitting C code dealing with complex floats
must be present even if the host doesn't support complex floats
natively.
Deciding whether to emit these instructions is implemented either by
explicit checks for *complex-float* or automatically as the compiler
will not create :c{s/d/l}float locations for a target without complex
float support (this is decided at runtime based on the contents
of *machine*).
The procedure works as follows. First, cross compile ECL itself. In
this step, we dump the configuration of the compiler. This
configuration can then be later restored to put the host compiler into
cross compilation mode using a new option to WITH-COMPILATION-UNIT.
The following changes to the public interface are introduced:
- WITH-COMPILATION-UNIT now takes a new :target keyword
- New functions C:WRITE-TARGET-INFO, C:READ-TARGET-INFO to dump and
restore the config
- The environment parameters to TYPEP and SUBTYPEP are no longer
unused. User macros can query type relationships in the target
environment using these parameters.
Internal changes in the compiler include:
- Target dependent variables in the compiler are defined using a new
DEFCONFIG macro. C:WRITE-TARGET-INFO simply writes the value of
these variables to a file.
- The distinction between target types and host types already exists
in the compiler. In this commit, we just register the target types in
the compiler environment when we change the compiler configuration.
Fixes a regression introduced in commit
816c08340b. After the changes in that
commit, c1forms of name variable can denote constants as well.
Since we are now more aggressive with inlining constant access, we
have to fix a bad defconstant definition in clos/boot.lsp as well (the
new definition makes sure that the compile-time and load-time
evaluations of the constant are eql).
Previously elementary types were considered to be (CONS SPECC TAG), but I want to
introduce additional slot information to them, so we define a structure for that
type. The representation a is list because MAYBE-SAVE-TYPES calls COPY-TREE. Also
DEFSTRUCT is not available yet.
Rename PUSH-TYPE to PUSH-NEW-TYPE and move it to a correct section in the file.
