aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/test
AgeCommit message (Collapse)Author
2016-09-21Simplify beam_utilsBjörn Gustavsson
When beam_utils was first written, it did not have the functions for testing whether a register was not used. Those were added later, in sort of a hacky way. Also, is_killed*() and is_not_used*() for Y registers would return the same answer. Fix that to make the API more consistent (an Y register can only be killed by a deallocate/1 instruction). We will need to change beam_trim to call beam_utils:is_not_used/3 instead of beam_utils:is_killed/3.
2016-09-21bs_match_SUITE: Add a test case for beam_utilsBjörn Gustavsson
During development, a bug in beam_utils caused a compiler failure in xmerl. If the bug reappears, make sure that we catch it when compiling the compiler test suite.
2016-09-21bif_SUITE: Cover the remaining uncovered linesBjörn Gustavsson
2016-09-14Merge branch 'maint'Björn Gustavsson
* maint: beam_validator: Handle unreachable instructions Turn off parallel make for start scripts Makefile
2016-09-13beam_validator: Handle unreachable instructionsBjörn Gustavsson
ab03678e introduced an optimization in the beam_z pass that could introduce unreachable code in BEAM files (a 'jump' instruction is removed after a 'raise' instruction, but the code following the target of the 'jump' is not removed). Since this situation happens very rarely, there is no point in adding another pass that can remove unreachable code after beam_z. Instead we will make sure that beam_validator can skip the unreachable code. Skipping unreachable code is already done in valfun_1/2 (for historical reasons), but we will also need to do it in val_dsetel/2.
2016-09-07Merge branch 'maint'Björn Gustavsson
* maint: [snmp] Correct bug when path to mib contains UTF-8 characters [ic] Fix but when UTF-8 character in path to idl spec sys_core_fold: Don't move a fun into a guard
2016-09-05sys_core_fold: Don't move a fun into a guardBjörn Gustavsson
Moving a fun into a guard may cause code that is not accepted by beam_validator.
2016-09-05Merge branch 'bjorn/floor-ceiling/OTP-13692'Björn Gustavsson
* bjorn/floor-ceiling/OTP-13692: Add math:floor/1 and math:ceil/1 Implement the new ceil/1 and floor/1 guard BIFs
2016-09-05Add math:floor/1 and math:ceil/1Björn Gustavsson
Add math:floor/1 and math:ceil/1 to avoid unnecessary conversions in floating point expressions. That is, instead of having to write float(floor(X)) as part of a floating point expressions, we can write simply math:floor(X).
2016-09-05Implement the new ceil/1 and floor/1 guard BIFsBjörn Gustavsson
Implement as ceil/1 and floor/1 as new guard BIFs (essentially part of Erlang language). They are guard BIFs because trunc/1 is a guard BIF. It would be strange to have trunc/1 as a part of the language, but not ceil/1 and floor/1.
2016-09-02Fix overridden BIFsBjörn Gustavsson
The filters in a list comprehension can be guard expressions or an ordinary expressions. If a guard expression is used as a filter, an exception will basically mean the same as 'false': t() -> L = [{some_tag,42},an_atom], [X || X <- L, element(1, X) =:= some_tag] %% Returns [{some_tag,42}] On the other hand, if an ordinary expression is used as a filter, there will be an exception: my_element(N, T) -> element(N, T). t() -> L = [{some_tag,42},an_atom], [X || X <- L, my_element(1, X) =:= some_tag] %% Causes a 'badarg' exception when element(1, an_atom) is evaluated It has been allowed for several releases to override a BIF with a local function. Thus, if we define a function called element/2, it will be called instead of the BIF element/2 within the module. We must use the "erlang:" prefix to call the BIF. Therefore, the following code is expected to work the same way as in our second example above: -compile({no_auto_import,[element/2]}). element(N, T) -> erlang:element(N, T). t() -> L = [{some_tag,42},an_atom], [X || X <- L, element(1, X) =:= some_tag]. %% Causes a 'badarg' exception when element(1, an_atom) is evaluated But the compiler refuses to compile the code with the following diagnostic: call to local/imported function element/2 is illegal in guard
2016-09-01compiler: Eliminate use of sys_pre_expandBjörn Gustavsson
sys_pre_expand previously did a lot more work, for example, translating records and funs, but now is merely a grab bag of small transformations. Move those transformations to v3_core.
2016-08-19Strengthen test case added in 8b83bc0bBjörn Gustavsson
Don't only test the case that failed; test it exhaustively.
2016-08-12Merge branch 'maint'Björn Gustavsson
* maint: asn1_test_lib: Compile ASN.1 modules in parallel Support 'make -j' when compiling ASN.1 modules [ERL-209] Fix ambiguous_catch_try_state inconsistency error
2016-08-11[ERL-209] Fix ambiguous_catch_try_state inconsistency errorBjörn Gustavsson
It is not safe to share code between 'catch' blocks.
2016-08-10Merge branch 'josevalim/large-binary-strings/PR-1131/OTP-13794'Björn Gustavsson
* josevalim/large-binary-strings/PR-1131/OTP-13794: Move expansion of strings in binaries to v3_core
2016-08-05Merge branch 'maint'Björn Gustavsson
* maint: Update primary bootstrap beam_block: Fix potentially unsafe optimization in move_allocates/1
2016-08-05beam_block: Fix potentially unsafe optimization in move_allocates/1Björn Gustavsson
beam_block has an optimization that only is safe when it is applied immediately after code generation. That is pointed out in a comment: NOTE: Moving allocation instructions is only safe because it is done immediately after code generation so that we KNOW that if {x,X} is initialized, all x registers with lower numbers are also initialized. That assumption may not be true after other optimizations, such as the beam_utils:live_opt/1 optimization. The new beam_reorder pass added in OTP 19 runs before beam_block. Therefore, the optimization is potentially unsafe. The optimization is also unsafe if compilation is started from assembly code in a .S file. Rewrite the optimization to make it safe. See the newly added comment for details. ERL-202
2016-08-04Move expansion of strings in binaries to v3_coreJosé Valim
This speeds up the compilation of binary literals with string values in them. For example, compiling a file with a ~340kB binary would yield the following times by the compiler: Compiling "foo" parse_module : 0.130 s 5327.6 kB transform_module : 0.000 s 5327.6 kB lint_module : 0.011 s 5327.8 kB expand_module : 0.508 s 71881.2 kB v3_core : 0.463 s 11.5 kB Notice the increase in memory and processing time in expand_module and v3_core. This happened because expand_module would expand the string in binaries into chars. For example, the binary <<"foo">>, which is represented as {bin, 1, [ {bin_element, 1, {string, 1, "foo"}, default, default} ]} would be converted to {bin, 1, [ {bin_element, 1, {char, 1, $f}, default, default}, {bin_element, 1, {char, 1, $o}, default, default}, {bin_element, 1, {char, 1, $o}, default, default} ]} However, v3_core would then traverse all of those characters and convert it into an actual binary, as it is a literal value. This patch addresses this issue by moving the expansion of string into chars to v3_core and only if a literal value cannot not be built. This reduces the compilation time of the file mentioned above to the values below: Compiling "bar" parse_module : 0.134 s 5327.6 kB transform_module : 0.000 s 5327.6 kB lint_module : 0.005 s 5327.8 kB expand_module : 0.000 s 5328.7 kB v3_core : 0.013 s 11.2 kB
2016-07-15Merge branch 'maint'Björn-Egil Dahlberg
Conflicts: OTP_VERSION
2016-07-12compiler: Test literal binary matchingBjörn-Egil Dahlberg
The following regression was introduced in 19.0: foo(bar, <<"x">>) -> 1; foo(_, <<"x">>) -> 2; foo(_, <<"y">>) -> 3; foo(_, _) -> fail. The call foo(bar,<<"y">>) would errorneous return 'fail' instead of 3. A testcase in match_SUITE has been added to verify this.
2016-06-29compiler: Eliminate num_bif_SUITEBjörn Gustavsson
num_bif_SUITE.erl was originally copied from the emulator test suite. It does not test much of the compiler. Therefore, remove num_bif_SUITE. Add a new test to bif_SUITE to test trunc/1 and round/1 in contexts that could be tricky for the compiler to handle correctly. Note that there is no need to test abs/1 in bif_SUITE, since it is tested in many other places (e.g. in guard_SUITE).
2016-06-07Compiler: new function env_compiler_options/0alisdair sullivan
retrieve the value of the environment variable ERL_COMPILER_OPTIONS in the same manner as used by file/2, forms/2 and output_generated/2
2016-06-03misc_SUITE: Cover the remaining lines in beam_peepBjörn Gustavsson
2016-06-02Avoid the dreaded "no_file" in warningsBjörn Gustavsson
Add more filename/line number annotations while translating to Core Erlang in v3_core, and ensure that sys_core_fold retains existing annotations. The goal is to avoid that sys_core_fold generate warnings with "no_file" instead of a filename.
2016-06-02Eliminate crash for map updates in guardsBjörn Gustavsson
beam_validator would complain that x(1) is uninitialized in a test_heap instruction when attempting to compile the following code with sys_core_fold turned off: foo(M) when not (M#{true := 0}); [M] -> ok. Simplified, the generated BEAM assembly code looked like this: test is_map BadMap x(0) put_map_exact Fail x(0) => x(1) ... jump BooleanStuff BadMap: move ok => x(1) jump Fail BooleanStuff: ... move Boolean => x(2) jump Build Fail: move false => x(2) Build: test_heap 2 3 %% x(0), x(1), x(2) must be live. ... That is, if put_map_exact failed, control would transfer to the label Fail without initializing x(1). Fix that by making sure that x(1) is initilized even if put_map_exact fails: test is_map BadMap x(0) put_map_exact BadLbl x(0) => x(1) ... jump OkLbl BadLbl: move ok => x(1) jump Fail OkLbl: jump BooleanStuff BadMap: move ok => x(1) jump Fail BooleanStuff: ... move Boolean => x(2) jump Build Fail: move false => x(2) Build: test_heap 2 3 %% x(0), x(1), x(2) must be live. ... Note that this situation is rare, and that other optimization passes (beam_dead and beam_jump in particular) will clean up this mess.
2016-06-01beam_block: Eliminate crash in beam_utilsBjörn Gustavsson
Somewhat simplified, beam_block would rewrite the target for the first instruction in this code sequence: move x(0) => y(1) gc_bif '+' 1 x(0) => y(0) move y(1) => x(1) move nil => x(0) call 2 local_function/2 The resulting code would be: move x(0) => x(1) %% Changed target. gc_bif '+' 1 x(0) => y(0) move x(1) => y(1) %% Operands swapped (see 02d6135813). move nil => x(0) call 2 local_function/2 The resulting code is not safe because the x(1) will be killed by the gc_bif instruction. 7a47b20c3a cleaned up move optimizations and would reject the optimization if the target was an X register and an allocating instruction was found. To avoid this bug, the optimization must be rejected even if the target is a Y register.
2016-05-31Add additional coverage and smoke test of beam_validatorBjörn Gustavsson
2016-05-30Eliminate unsafe use of Y registersBjörn Gustavsson
If the Core Erlang optimization were turned off (using no_copt), the optimization passes for Beam assembly could generate unsafe code that did not initialize all Y registers before (for example) a call instruction. To fix this, beam_dead should not attempt to remove stores to Y registers. That is not safe if there is an exception-generating instruction inside a try...catch block.
2016-05-30beam_validator: Add is_bitstring/1 as a safe BIFBjörn Gustavsson
beam_validator wrongly complained that the following was not safe because it didn't know that is_bitstring/1 is safe: food(Curriculum) -> [try is_bitstring(functions) catch _ -> 0 end, Curriculum]. While we are it, also add a new bif_SUITE test suite to cover some more code in beam_validator.
2016-05-25beam_jump: Clean up handling of labels before func_infoBjörn Gustavsson
In complicated code with many indirect jumps to the func_info label, a label could get lost.
2016-05-25beam_expect: Correctly handle blocks with multiple allocsBjörn Gustavsson
A negative allocation could be calculated if a block had multiple allocations. Make sure to process the block in the right order so that the correct allocation is processed. Also add an assertion. This bug was often not noticed because beam_type usually silently recalculates the allocation amount in test_heap/2 instructions.
2016-05-25v3_codegen: Don't confuse beam_validatorBjörn Gustavsson
Generate code that not only is safe, but can easily be seen by beam_validator to be safe.
2016-05-25v3_codegen: Correct code generation for an error/1 call in a guardBjörn Gustavsson
Sometimes v3_codegen would generate unsafe code when there was a call to error/1 in a guard.
2016-05-25beam_receive: Don't crash when encountering nonsensical codeBjörn Gustavsson
2016-05-23beam_bool_SUITE: Cover one more lineBjörn Gustavsson
2016-05-23beam_utils_SUITE: Cover more lines in beam_utilsBjörn Gustavsson
By first adding a call to error/1 to each uncovered line, QuickCheck could find test cases that would cover the lines.
2016-05-23beam_reorder: Don't confuse beam_validatorBjörn Gustavsson
Make sure we don't optimize code such as: is_tuple Fail Src test_arity Fail Src Arity get_tuple_element Src Pos Dst is_map Fail Src If we would reorder the instructions like this: is_tuple Fail Src test_arity Fail Src Arity is_map Fail Src get_tuple_element Src Pos Dst beam_validator would complain that the type for Src is a map instead of a tuple. Since the code has problems to begin with, there is no need to do the optimization.
2016-05-23beam_bool: Reject potentially unsafe optimizationBjörn Gustavsson
When calculating the sets of registers that must be killed or unused, registers set in a {protected,_,_,_} block were not considered. That could result in a crash in the assertion in beam_utils:live_opt_block/4.
2016-05-23v3_core: Don't depend on sys_core_fold for cleaning upBjörn Gustavsson
a3ec2644f5 attempted to teach v3_core not to generate code with unbound variables. The approach taken in that commit is to discard all expressions following a badmatch. That does not work if the badmatch is nested: {[V] = [] = foo,V}, V That would be rewritten to: {error({badmatch,foo})}, V where V is unbound. If we were to follow the same approach, the tuple construction code would have to look out for a badmatch. As would list construction, begin...end, and so on. Therefore, as it is impractical to discard all expressions that follow a badmatch, the only other solution is to ensure that the variables that the pattern binds will somehow be bound. That can be arranged by rewriting the pattern to a pattern that binds the same variables. Thus: error({badmatch,foo}), E = foo, case E of {[V],[]} -> V; Other -> error({badmatch,Other} end
2016-05-23beam_type: Eliminate crashBjörn Gustavsson
The following code: simple() -> case try 0 after [] end of 0 -> college; 1 -> 0 end. would crash the compiler like this: crash reason: {case_clause, {'EXIT', {function_clause, [{beam_type,simplify_select_val_int, [{select,select_val, {x,0}, {f,7}, [{integer,1},{f,9},{integer,0},{f,8}]}, 0], [{file,"beam_type.erl"},{line,169}]}, {beam_type,simplify_basic_1,3, [{file,"beam_type.erl"},{line,155}]}, {beam_type,opt,3,[{file,"beam_type.erl"},{line,57}]}, {beam_type,function,1,[{file,"beam_type.erl"},{line,36}]}, {beam_type,'-module/2-lc$^0/1-0-',1, [{file,"beam_type.erl"},{line,30}]}, {beam_type,module,2,[{file,"beam_type.erl"},{line,30}]}, {compile,'-select_passes/2-anonymous-2-',2, [{file,"compile.erl"},{line,521}]}, {compile,'-internal_comp/4-anonymous-1-',2, [{file,"compile.erl"},{line,306}]}]}}} The root cause is that the type representation is not well-defined. Integers could be represented in three different ways: integer {integer,{1,10}} {integer,0} However, only the first two forms were handled. To avoid similar problems in the future: * Make the type representation stricter. Make sure that integers are only represented as 'integer' or {integer,{Min,Max}}. * Call verify_type/1 whenever a new type is added (not only when merging types) to ensure that only the supported types are added to the type database). (ERL-150)
2016-05-20beam_type: Correct handling of setelement/3Björn Gustavsson
We must be careful how we treat the type info for the result of: setelement(Index, Tuple, NewValue) If Tuple had type information, the result of setelement/3 (in x(0)) would be assigned the same type information. But that is not safe for: setelement(1, Tuple, NewValue) since the type for the first element will be changed. Therefore, we must take care to remove the type information for the first element of the tuple if might have been modified by setelement/3.
2016-05-16Merge branch 'bjorn/compiler/beam_bool/ERL-143'Björn Gustavsson
* bjorn/compiler/beam_bool/ERL-143: Eliminate crash in beam_bool Add beam_bool_SUITE Add missing test cases in andor_SUITE and beam_block_SUITE
2016-05-16Eliminate crash in beam_boolBjörn Gustavsson
beam_bool would crash when attempting to optimize BEAM code similar to this code: bif '=:=' Reg1 SomeValue => y(0) bif '=:=' Reg2 {atom,true} => x(2) bif '=:=' Reg3 {atom,true} => x(3) bif 'or' x(2) x(3) => x(2) is_eq_exact Fail x(2) {atom,true} The problem is that the first instruction that assigns a value to a Y register. beam_bool:ssa_assign/2 will not accept a Y register argument. We could change ssa_assign/2 to accept a Y register, but that would only cause the entire optimization to be rejected later because the Y register is alive in the code that follows. Therefore, a better solution is to modify extend_block/3 so that the instruction that assign to Y registers are not added to the block. That is, the optimizer will only operate on the following code: bif '=:=' Reg2 {atom,true} => x(2) bif '=:=' Reg3 {atom,true} => x(3) bif 'or' x(2) x(3) => x(2) is_eq_exact Fail x(2) {atom,true} Usually the optimization will succeed, rewriting the four instructions to a select_val instruction. Assembly code such as the above can be produced by code similar to: Y = Something == SomethingElse, case Y of Condition; OtherCondition -> . . . end, . . ., Y. Reported-by: http://bugs.erlang.org/browse/ERL-143 Reported-by: José Valim
2016-05-16Add beam_bool_SUITEBjörn Gustavsson
It's time that we have a dedicated test suite for beam_bool.
2016-05-16Add missing test cases in andor_SUITE and beam_block_SUITEBjörn Gustavsson
Two test cases were not actually run. Even if their main purpose is to ensure that the compiler doesn't crash, we always try to also run the test case (when practial) to also ensure that the generated code is correct.
2016-05-13compile_SUITE: Cover numeric variable names in core_ppBjörn Gustavsson
The inliner generates variable whose names are numeric. Run the inliner to cover one more line in core_pp.
2016-05-13compile_SUITE: Eliminate clones when re-compiling test suitesBjörn Gustavsson
Several test cases in compile_SUITE (e.g. core/1) extracts the abstract code from a BEAM file and runs the compiler on it. It is only a waste of time to use the abstract code from cloned versions of test case modules. That is, use record_SUITE, but don't use record_no_opt_SUITE, record_post_opt_SUITE, or record_inline_SUITE since they all contain essentially the same abstract code.
2016-05-13test_lib: Add is_cloned_mod/1Björn Gustavsson
Add is_cloned_mod(Mod) to determine whether Mod is the original name for a module (e.g. record_SUITE) or a cloned module (e.g. record_no_opt_SUITE).
2016-05-13trycatch_SUITE: Cover the only uncovered line in sys_core_foldBjörn Gustavsson
Recent spring cleaning in the test suite left a line in sys_core_fold dealing with an unnecessary catch uncovered.