| Age | Commit message (Collapse) | Author |
|---|
|
* rj/fix-remove-exec-bit:
Remove exec bit from files: info files, dat, bat
Remove exec bit from files related to: XML, make, C
Remove exec bit from: erl, hrl, xml, html, asn, gif, xpm
OTP-9698
|
|
* rj/fix-erlang-doc-style:
Fixes module erlang doc style: option description
OTP-9697
|
|
|
|
|
|
* sverk/bif-args/OTP-9662:
erts,hipe: Limited support for hipe cross compilation
erts-hipe: Change THE_NON_VALUE for HiPE enabled debug emulator
erts-hipe: Enable debug compiled hipe-VM with lock checker
erts-hipe: Rename fail_bif_interface_0 to standard_bif_interface_0
erts-hipe: Deliberate leak of native fun entries
erts-hipe: Fix new trap conventions for x86, amd64 and ppc
Store the trap address in p->i
Store the trap arguments in the X register array
erts-hipe: Make some primops use new BIF calling convention
erts-hipe: Adapt generated BIF wrappers for new calling convention
erts-hipe: Remove obscuring macros in generated assembler code
erts-hipe: Make hipe enabled emulator compile with new BIF calls
Simplify the instructions for calling BIFs
Change the calling convention for BIFs
Use the proper macros in all BIFs
Conflicts:
erts/emulator/beam/bif.h
erts/emulator/beam/erl_bif_info.c
|
|
Normally hipe assumes that generated native code will be executed
on the same emulator as the hipe compiler is running on.
This commit allows you to build a hipe "cross-compiler"
for a different configured emulator (but for same architecture).
Example:
> cd lib/hipe
> make clean
> make XCOMP=yes FLAVOR=smp TYPE=debug
This hipe compiler will generate code to be executed
on the debug compiled smp-emulator at $ERL_TOP.
|
|
* sverk/enif_inspect-memleak/OTP-9668:
erts: Fix memory leak of enif_inspect_* on independent environment
|
|
* bjorn/create-less-garbage:
Optimize filename:basename/1 to produce less garbage
Optimize filename:extension/1 to produce less garbage
sys.c for Unix: Undo caching of utsname in os_flavor()
Pre-build the tuples returned by os:type/0 and os:version/0
|
|
* egil/fix-compiler-warnings:
erts: Remove unused variable in enif_make_binary
erts: Remove debug variable in list_to_binary
erts: Remove cp on exiting and trapping processes
erts: Remove debug variables in erl_db
erts: Remove dead code in efile_drv
erts: Remove lock_check debug variables
erts: Remove unused variable in ttsl_drv
erts: "initialized" is only used with CHLDWTHR
erts: remove debug variables in beam_bp
|
|
OTP-9675
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* bjorn/fun-improvements/OTP-9667:
sys_pre_expand: Remove incorrect comment
compiler: Eliminate use of deprecated erlang:hash/2
beam_asm: Fix broken NewIndex in fun entries
beam_asm: Strenghten the calculation of Uniq for funs
|
|
Funs are identified by a triple, <Module,Uniq,Index>, where Module is
the module name, Uniq is a 27 bit hash value of some intermediate
representation of the code for the fun, and index is a small integer.
When a fun is loaded, the triple for the fun will be compared to
previously loaded funs. If all elements in the triple in the newly
loaded fun are the same, the newly loaded fun will replace the previous
fun. The idea is that if Uniq are the same, the code for the fun is also
the same.
The problem is that Uniq is only based on the intermediate representation
of the fun itself. If the fun calls local functions in the same module,
Uniq may remain the same even if the behavior of the fun has been changed.
See
http://erlang.org/pipermail/erlang-bugs/2007-June/000368.htlm
for an example.
As a long-term plan to fix this problem, the NewIndex and NewUniq
fields was added to each fun in the R8 release (where NewUniq is the
MD5 of the BEAM code for the module). Unfortunately, it turns
out that the compiler does not assign unique value to NewIndex (if it
isn't tested, it doesn't work), so we cannot use the
<Module,NewUniq,NewIndex> triple as identification.
It would be possible to use <Module,NewUniq,Index>, but that seems
ugly. Therefore, fix the problem by making Uniq more unique by
taking 27 bits from the MD5 for the BEAM code. That only requires
a change to the compiler.
Also update a test case for cover, which now fails because of the
stronger Uniq calculation. (The comment in test case about why the
Pid2 process survived is not correct.)
|
|
Currently, the external fun syntax "fun M:F/A" only supports
literals. That is, "fun lists:reverse/1" is allowed but not
"fun M:F/A".
In many real-life situations, some or all of M, F, A are
not known until run-time, and one is forced to either use
the undocumented erlang:make_fun/3 BIF or to use a
"tuple fun" (which is deprecated).
EEP-23 suggests that the parser (erl_parse) should immediately
transform "fun M:F/A" to "erlang:make_fun(M, F, A)". We have
not followed that approach in this implementation, because we
want the abstract code to mirror the source code as closely
as possible, and we also consider erlang:make_fun/3 to
be an implementation detail that we might want to remove in
the future.
Instead, we will change the abstract format for "fun M:F/A" (in a way
that is not backwards compatible), and while we are at it, we will
move the translation from "fun M:F/A" to "erlang:make_fun(M, F, A)"
from sys_pre_expand down to the v3_core pass. We will also update
the debugger and xref to use the new format.
We did consider making the abstract format backward compatible if
no variables were used in the fun, but decided against it. Keeping
it backward compatible would mean that there would be different
abstract formats for the no-variable and variable case, and tools
would have to handle both formats, probably forever.
Reference: http://www.erlang.org/eeps/eep-0023.html
|
|
A future release of the compiler might want to treat external
funs as literals. Make sure that the loader can cope with an
export entry being created from both an entry in the literal
pool and from the export table (i.e. if an external fun refers
to an exported function in the same module).
|
|
Make it clear for the user what has happened and how to fix it when
an attempt is made to load a BEAM file containing new instructions
that the current run-time system cannot handle.
Suggested-by: Thomas Lindgren
|
|
* lukas/erts/large_float_cmp/OTP-9497:
Update documentation after changes in integer and float comparison
Do small optimisation on platforms with 32 bit Eterm
Add tests for equality checking
Optimize comparison of huge floats and smaller bignums
Add tests for comparing large floats and small bignums
Cleanup double_to_bignum conversion code
Update size of tmp cmp bignum buffer
Expand tests for float and number comparison
Update heauristic to work on halfword
Add heauristics bignum vs float checks
Optimise bugnum and small comparison
Add float vs integer comparison tests
Update integer and floating point number comparisons
|
|
Affects enif_inspect_iolist_as_binary() on iolists
and enif_inspect_binary() on byte-unaligned binaries.
Also need to allocate inspection buffers in ERTS_ALC_T_NIF for
process independent environments, as we don't know when and where
the environment will be freed.
|
|
and some added comments
|
|
These dependency files was once used when building the documentation,
but are no longer needed.
|
|
|
|
|
|
This is a work-around as there are hipe BIFs that return untagged
integers that may be intepreted as THE_NON_VALUE (24).
Hipe bifs that return offsets as untagged integers:
hipe_bs_put_utf8
hipe_bs_put_utf16be
hipe_bs_put_utf16le
Hipe bifs that return raw pointers:
hipe_find_na_or_make_stub
hipe_nonclosure_address
|
|
Add hipe_debug_bif_wrapper() as a wrapper for every BIF
called by native code.
|
|
|
|
This is a workaround as hipe code upgrade/unloading does not work properly.
|
|
|
|
For cleanliness, store the trap address in p->i instead of in
p->def_arg_reg[3].
|
|
Store arguments for a trap in the X register array to allow
traps to have any number of arguments.
|
|
These primops use the standard_bif_interface_X macros in
hipe_bif_list.m4 and must therefor be implemented as bifs for things to work.
Maybe there is room for optimization here to call the primops more directly
with arguments in registers without having to push them on stack to emulate
bif calls.
|
|
x86 and amd64: Push BIF__ARGS array on C-stack.
ppc, sparc and arm: Write BIF__ARGS array to P->def_arg_reg[]
Just the simplest solution with limited assembler knowledge,
probably room for improvements.
|
|
No semantic change.
Just easier to debug when jumps are spelled out
and not obscured by yet another layer of macros.
|
|
A first step to adapt hipe to the new BIF calling convention.
|
|
Taking advantage of the new calling convention for BIFs, we
only need one instruction to handle BIFs with any number of
arguments. This change eliminates the limit of three arguments
for BIFs, but traps are still limited to three arguments.
|
|
The current calling convention for BIFs makes it necessary to
handle each arity specially, since each argument for the BIF
also becomes an argument for the C function implementing the BIF,
which makes it hard to allow BIFs with any number of arguments.
Change the calling convention for BIFs, so that BIF arguments are
passed in an array to the C function implementing the BIF.
|
|
As a preparation for changing the calling convention for
BIFs, make sure that all BIFs use the macros. Also, eliminate
all calls from one BIF to another, since that also breaks
the calling convention abstraction.
|
|
* bjorn/unicode-noncharacters/OTP-9624:
Allow noncharacter code points in unicode encoding and decoding
|
|
Previously removed code erroneously reappeared in a merge to the master
branch (ec36499d7e329b4dc69a1a3be3422eac7907c260).
|
|
|
|
* fm/enif_is_number:
Add NIF function enif_is_number
Conflicts:
erts/emulator/beam/erl_nif_api_funcs.h
OTP-9629
|
|
|
|
The two noncharacter code points 16#FFFE and 16#FFFF were not
allowed to be encoded or decoded using the unicode module or
bit syntax. That causes an inconsistency, since the noncharacters
16#FDD0 to 16#FDEF could be encoded/decoded.
There is two ways to fix that inconsistency.
We have chosen to allow 16#FFFE and 16#FFFF to be encoded and
decoded, because the noncharacters could be useful internally
within an application and it will make encoding and decoding
slightly faster.
Reported-by: Alisdair Sullivan
|
