| Age | Commit message (Collapse) | Author |
|---|
|
* dev:
sys_pre_expand: Don't duplicate options given in the source code
|
|
* bjorn/compiler-options/OTP-9534:
sys_pre_expand: Don't duplicate options given in the source code
|
|
Any compiler options given with a -compile() attribute in source file
would be included both at the beginning and the end of the option list
for the compiler. Including the options twice is harmless during
compilation, but since the options will also be available in
Mod:module_info(compile), including them twice will waste memory.
Include the options from the source first in the list so that they
override options given on the command line.
|
|
Conflicts:
lib/asn1/doc/src/asn1ct.xml
|
|
|
|
|
|
|
|
Also update the r12 and r13 options so that they imply no_line_info.
|
|
In the location information tables in the run-time system, source
filenames that are the same as the module name plus ".erl" extension
are not stored explicitly, thus saving memory.
To take advantage of that optimization, avoid complicating the names of
files in the current working directory; specifically, make sure that
"./" is not prepended to the name.
|
|
|
|
|
|
Introduce the line/1 instruction in the compiler and the BEAM
virtual machine. It will not yet be generated by the compiler and
will not actually carry any information.
|
|
|
|
|
|
'eval_bits' is a common utility module used for evaluting binary
construction and matching. The functions that do matching
(match_bits/{6,7} and bin_gen/6) are supposed to treat the bindings as
an abstract data type, but they assume that the bindings have the same
representation as in the erl_eval module. That may cause binary
matching to fail in the debugger, because the debugger represents the
bindings as an unordered list of two-tuples, while the erl_eval
modules uses an ordered list of two-tuple (an ordset).
One way to fix the problem would be to let the debugger to use ordered
lists to represent the bindings. Unfortunately, that would also change
how the bindings are presented in the user interface. Currently, the
variable have most been recently assigned is shown first, which is
convenient.
Fix the matching problem by mending the leaky abstraction in
eval_bits. The matching functions needs to be passed two additional
operations: one for looking up a variable in the bindings and one for
adding a binding. Those operations could be passed as two more funs
(in addition to the evaluation and match fun already passed), but the
functions already have too many arguments. Therefore, change the
meaning of the match fun, so that the first argument is the operation
to perform ('match', 'binding', or 'add_binding') and second argument
is a tuple with arguments for the operation.
|
|
concat_binary/1 was deprecated in R13B04, but already in
the R10B-2 release, the documentation recommends using
list_to_binary/1 instead.
|
|
|
|
In warning_translate_label/2, gb_trees:lookup/2 is called
to translate from the entry label for a function to its name.
Since the gb_tree has an entry for all functions in the module,
there is no way that the lookup can fail unless there is a
serious bug.
Therefore, use gb_trees:get/2 so that an exception and an
internal compiler error will be generated if the lookup would
ever fail.
|
|
There is never any empty blocks when beam_dead is invoked.
Even if there were, they will be removed a little bit later in
forward/4.
|
|
In the optimization of binary matching, it seems that two clauses
cannot never be reached. Removing the clauses is safe, since that
would only mean that an opportunity for an optimization is lost
|
|
Because the code generator (v3_codegen) would not include the
same value more than once in a select_val/3 instruction and
because a label can only be referenced by one select_val/3
instruction, there is no way that the correct value could already
be in the gb_tree. (Even if it could happen, this change is
safe because only opportunity for an optimization would be missed;
incorrect code would not be generated.)
|
|
Since the optimizations in forward/4 already depends on some
assumptions on how code is generated anyway, document the
assumptions in a comment and remove the uncoverable code.
|
|
It is not needed because it can be trivially calculated using
gb_trees:size/1.
|
|
|
|
The compiler (sys_core_fold) tries to avoid constructing tuples
in case expressions. The following code:
c(A, B) ->
case {A,B} of
{ok,X} -> X;
{_,_} -> error
end.
will be rewritten so that no tuple is built. If a clause
requires a tuple to be built as in this code:
c(A, B) ->
case {A,B} of
{ok,X} -> X;
V -> V %The tuple will be built here
end.
the tuple will be built in the clause(s) in which it is needed.
If the value returned from the case is not used as in this code:
c(A, B) ->
case {A,B} of
V -> V %Warning: a term is constructed, but never used
end,
ok.
there will be an incorrect warning. Basically, what happens is
that the code is reduced to:
c(A, B) ->
{A,B}, %Warning: a term is constructed, but never used
ok.
and the optimizer sees that the {A,B} tuple can't possibly be used.
Eliminate the warning by adding a 'compiler_generated' annotation
to the tuple.
Reported-by: Kostis Sagonas
|
|
|
|
In the following code:
m(<<Sz:8,_:Sz/binary>>) ->
Sz = wrong.
the Sz variable is supposed to be bound in the function header and the
matching "Sz = wrong" should cause a badarg exception. But what
happens is that the Sz variables seems to be unbound and the matching
succeds and the m/1 function returns 'wrong'.
If the Sz variable is used directly (not matched), it will have
the expected value. Thus the following code:
m(<<Sz:8,_:Sz/binary>>) ->
Sz.
will correctly return the value of Sz that was matched out from
the binary.
Reported-by: Bernard Duggan
|
|
|
|
|
|
* bjorn/fix-dialyzer-warnings:
v3_kernel_pp: Eliminate dialyzer warning
inet6_tcp_dist: Eliminate dialyzer warning for "tuple fun"
|
|
* bjorn/compiler/refactor-source-options:
compile: Refactor handling of source options (e.g. 'from_core')
|
|
Use conditional compilation instead of a run-time test.
Will also improve the coverage of the code.
|
|
* jp/dependencies_makefile:
Add dependencies Makefile generation to erlc(1) and compile(3)
Conflicts:
lib/compiler/test/compile_SUITE.erl
OTP-9065
|
|
This is useful when a project is built with Makefiles and erlc(1)
instead of EMakefiles. Tracking dependencies by hand is error-prone and
it becomes painful when using external application headers like EUnit's
one.
A dependencies Makefile will look like this:
module.beam: module.erl \
/usr/local/lib/erlang/lib/eunit-2.1.4/include/eunit.hrl \
header.hrl
When included in the main Makefile, 'module' will be recompiled only
when needed.
GCC offers the same feature and new erlc(1) options are compatible with
it.
More informations at:
http://wiki.github.com/dumbbell/otp/dependencies-makefile
|
|
The options for compiling from Core Erlang, BEAM assembler files,
and BEAM files are handled in several places, making it difficult
to change or add more similar options. Refactor the option handling
so that each option only need to be handled in one place.
|
|
* bjorn/compiler/eliminate-warnings:
compiler Makefile: Turn warnings into errors
v3_kernel_pp: Add support for pretty-printing #k_literal{} records
v3_kernel_pp: Eliminate warning
|
|
By accident a previous instance of St is used, which is
harmless in this case, but leads to worse quality of
the generated code.
|
|
We want to ensure that the compiler applications is kept
free of warnings.
|
|
|
|
|
|
Similar to -spec and -type, -export_type should be not be included
as attributes (and therefore loaded) in BEAM files, but only in
the abstract code chunk.
|
|
Sometimes the beam_bool pass wants to know whether an
y register will be killed by the code that follows and
will do (effectively):
beam_utils:is_killed({y,Y}, Code, L)
When asked to calculate the liveness for an y register,
beam_utils:is_killed/3 will loop forever if the code
includes a receive loop.
Since this rarely occurs, fix the problem in the simplest
and most conservative way.
Reported-by: Christopher Williams
|
|
When gc_bif instructions occurred outside of a block,
beam_utils:check_liveness/3 did not take into account
that the instruction could do a garbage collection, and
could falsely report that an x register would be killed.
That could cause the beam_dead pass to make the code
unsafe by removing the assignment to an x register that
would subsequently be referenced by the garbage collector.
Reported-by: Christopher Williams
|
|
* ks/strengthen-specs:
lists: Strengthen and modernize specs
syntax_tools: Fix an erroneous type and strengthen some specs
ordsets: Export ordset/1 type and strengthen specs
compiler: Strengthen some specs to shut off dialyzer warnings
|
|
|
|
Moving of allocation instructions upwards in the instruction
stream (in order to enable further optimizations) in beam_block,
is implemented with the assumption that if a register {x,X}
contains a valid term, then all other x register with lower
numbers than X also contain valid terms. That assumption is
true after code generation.
The beam_utils:live_opt/1 optimization, however, may invalidate
that assumption. For instance, if a receive statement exports a
variable that is used, but the return value of the receive statement
is not used, then {x,1} but not {x,0} contains a valid term at the
end of the receive statement. If the receive statement is
followed by
{bif,self,{f,0},[],{x,0}}.
{test_heap,NumberOfWords,2}.
moving the allocation upwards will produce
{test_heap,NumberOfWords,2}.
{bif,self,{f,0},[],{x,0}}.
which will cause the beam_validator pass to scream loudly that
{x,0} is not live at the test_heap instruction.
Fix the problem by doing the optimizations in reverse order.
Reported-by: Jim Engquist
|
|
Silence the Dialyzer warning introduced in commit
7b283aa9507b45f2cd403b061ad92ab059fb71b5.
|
|
* bjorn/compiler-bin-generators/OTP-8864:
core_lint: Enforce that tail segments only occur at the end
Don't generate multiple tail segments in binary matching
Factor out some of the code for binary generators
Add tests for tail segments in binary generators
|
|
|
|
Code such as
foo(A) -> <<A:0>>.
would cause a compiler crash.
|
