aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/test
AgeCommit message (Collapse)Author
2012-03-14Merge branch 'bjorn/compiler/coverage-and-minor-fixes/OTP-9982' into maintBjörn Gustavsson
* bjorn/compiler/coverage-and-minor-fixes/OTP-9982: v3_life: Use common code for guards and bodies v3_core: Don't put negative line numbers in annotations v3_kernel: Dig out the line number only when generating a warning v3_kernel: Clean up handling of guards v3_kernel: Introduce is_in_guard/1 v3_kernel: Removed unreached clause for #k_bin_int{} in sub_size_var/1 v3_kernel: Remove unreached handling of #k_bin_int{} in arg_con/1 v3_codegen: Eliminate the special case of 'put' without destination v3_kernel: Don't attempt to share identical literals v3_kernel: Handle sequences in guards v3_kernel: Remove clauses that are never executed in arg_val/1 v3_kernel.hrl: Remove unused record #k_string{} v3_kernel.erl: Remove unused define of EXPENSIVE_BINARY_LIMIT sys_core_fold: Refactor previous_ctx_to_binary/2 to cover it completely sys_core_fold: Fix opt_guard_try/1 sys_core_fold: Simplify opt_bool_not() to cover it completely sys_core_fold: Remove duplicate optimization
2012-02-21Merge branch 'ks/compile_info-fix' into maintGustav Simonsson
* ks/compile_info-fix: compiler: Fix discrepancy in compile_info OTP-9917
2012-02-20Fix discrepancy in compile_infoKostis Sagonas
The BEAM disassembler used the atom 'none' to signify the absence of a compile_info chunk in a .beam file. This clashes with the type declaration of the compile_info field of a #beam_file{} record as containing a list. Use [] to signify the absence of this chunk. This simplifies the code and avoids a dialyzer warning. For fixing a similar problem and for consistency, changed also the return type of the attributes field of the #beam_file{} record. This required a change in the beam_disasm test suite.
2012-02-13compiler: Teach the inliner to preserve on_load functionsBjörn Gustavsson
The inliner was ignorant of on_load functions and would discard them (unless they were exported or referenced). Noticed-by: Yiannis Tsiouris <[email protected]>
2012-01-25compile_SUITE: Eliminate race conditionBjörn Gustavsson
Compiling the same source code with the same options may not produce the same BEAM file because the compilation time is included in the "CInf" chunk.
2012-01-18compiler: Correct live calculation when get/1 is used in try...catchBjörn Gustavsson
In the following code excerpt, the instruction marked below was incorrectly removed: . . . {'try',{y,2},{f,TryCaseLabel}}. {bif,get,{f,0},[{x,0}],{x,0}}. {move,{x,1},{y,0}}. {move,{x,3},{y,1}}. <======= Incorrectly removed {jump,{f,TryEndLabel}}. {label,TryEndLabel}. {try_end,{y,2}}. {deallocate,3}. return. {label,TryCaseLabel}. {try_case,{y,2}}. . . . beam_utils indicated that {y,1} was not used at TryEndLabel, which by itself is correct. But it is still not safe to remove the instruction, because {y,1} might be used at TryCaseLabel if an exception occurs. Noticed-by: Eric Merritt
2012-01-11v3_kernel: Handle sequences in guardsBjörn Gustavsson
A guard with a sequence will cause a crash in v3_codegen. Currently, it seems that a sequence in a guard will never happen when compiling from Erlang code, but there are several reasons to fix this problem anyway: * There are other compilers that generate Core Erlang code. * Changes to sys_core_fold (perhaps additional optimizations) may cause sequences to be generated in guards. * A previously uncovered line in sys_core_fold:opt_guard_try/1 will now be covered.
2012-01-11sys_core_fold: Fix opt_guard_try/1Björn Gustavsson
opt_guard_try/1 assumed that it was only operating on guards, and implicitly assumed that any function call was to BIFs without any side effects.
2012-01-11compile_SUITE: Add test of 'sys_pre_attributes'Björn Gustavsson
2012-01-05Correct syntax in compiler.coverBjörn Gustavsson
Modules would not get excluded. While at it, no longer exclude sys_pre_attributes since we will want to test it.
2012-01-04Cover v3_kernel:get_line/1Björn Gustavsson
2012-01-04core_SUITE: Cover the nomatch_shadow warning in v3_kernelBjörn Gustavsson
2012-01-04core_SUITE: Cover v3_kernel:build_match/2Björn Gustavsson
2012-01-04bs_match_SUITE: Add a test case to cover bsm_ensure_no_partition_2/5Björn Gustavsson
Also correct the comment in bsm_ensure_no_partition_2/5, and while at it correct typos in the comment for bsm_nonempty/2.
2012-01-04core_fold_SUITE: Cover sys_core_fold:is_safe_bool_expr_1/3Björn Gustavsson
2012-01-04core_SUITE: Cover sys_core_fold:eval_is_boolean/2Björn Gustavsson
2012-01-04core_SUITE: Cover sys_core_fold:make_effect_seq/2Björn Gustavsson
We need to write a test case in Core Erlang in order to cover make_effect_seq/2, since v3_core does not generate "deep" Core Erlang code.
2012-01-04beam_validator_SUITE:beam_files/1: Validate modules in parallelBjörn Gustavsson
2012-01-04compilation_SUITE: Compile compiler modules in parallelBjörn Gustavsson
On my Mac Pro with 8 cores, this change make self_compile/1 more than twice as fast, and self_compile_old_inliner/1 more than 4 times faster.
2012-01-04compilation_SUITE: Prevent cover from being run on slave nodesBjörn Gustavsson
In the self compilation test cases, the compiler compiles itself and runs the newly compiled version on a slave node. Having the cover server starting on the slave node defeats the purpose of the test, since it will load the SAME cover-compiled code on the slave node. (It will also be slower, but will not improve coverage since it compiles the same source files again.) Use a shielded node to prevent the cover server from getting started on the slave node.
2012-01-04test_lib:p_run/2: Be careful about how many parallel processes we useBjörn Gustavsson
We probably don't gain anything by using more processes than available schedulers. Also, if 'cover' is being run, using more than one process may make it slower, so we will be very conservative and use only one process in that case.
2012-01-04Remove part_eval_SUITEBjörn Gustavsson
This test suite has been superseded by other test suites (e.g. guard_SUITE). Removing it does not decrease the coverage.
2012-01-04Add the beam_except pass to optimize exceptionsBjörn Gustavsson
In order to save space, rewrite suitable calls to erlang:error/{1,2} to special BEAM instructions. This code is probably longer than the code taken out of v3_life and v3_codegen in the previous commit, but it is much easier to understand and maintain since the BEAM assembler format is better understood than the v3_life format.
2012-01-04Eliminate the match_fail primop in v3_kernel and later passesBjörn Gustavsson
In the v3_life pass, it is assumed that a 'match_fail' primop only occur at the top-level and at the end of a function. But this code: do_split_cases(A) -> case A of x -> Z = dummy1; _ -> Z = dummy2, a=b end, Z. will be optimized by sys_core_fold to the following code: 'split_cases'/1 = fun (_cor0) -> let <_cor7,Z> = case _cor0 of <'x'> when 'true' -> < 'dummy1','dummy1' > <_cor6> when 'true' -> %% Here follows a 'match_fail' primop inside %% multiple return values: < primop 'match_fail'({'badmatch','b'}),'dummy2' > end in Z moving the 'match_fail' primop into a "values" construction. In the future, we would like to get rid of the v3_life pass (it is there for historical reasons), so in the mean-time we prefer to not add more code to it by generalizing the handling of 'match_fail'. Since the 'match_fail' primop can be simulated by erlang:error/{1,2}, the simplest solution is to translate 'match_fail' to a call to erlang:error/{1,2} in v3_kernel and remove the handling of 'match_fail' in v3_life and v3_codegen. It is tempting to get rid of 'match_fail' also in the Core Erlang format, but there are two issues: - Removing the support for 'match_fail' completely may break tools that generate Core Erlang code. We should not do that in a minor release. - There is no easy way to generate a 'function_clause' exception that will remain correct if it will be inlined into another function. (Calling "erlang:error(function_clause, Args)" is fine only if it is not inlined into another function.) A good solution probably involves introducing new instructions, which is better done in a major release. Noticed-by: Håkan Matsson Minimized-test-case-by: Erik Søe Sørensen
2011-12-09Update copyright yearsBjörn-Egil Dahlberg
2011-12-06inline_SUITE: Add the comma_splitter/1 test caseBjörn Gustavsson
Compilation would fail with an error message similar to: comma_splitter: function split_at_comma/2+32: Internal consistency check failed - please report this bug. Instruction: {put,{x,0}} Error: {match_context,{x,0}}: Noticed-by: René Kijewski
2011-11-28Merge branch 'bjorn/compiler/options/OTP-9752'Björn Gustavsson
* bjorn/compiler/options/OTP-9752: filename documentation: Recommend against using filename:find_src/1,2 Teach filename:find_src/1,2 to handle slim or stripped BEAM files filename: Eliminate failing call to Mod:module_info(source_file) filename.erl:filter_options/1: Remove handling of dead options compiler: Don't include {cwd,_} in module_info(compile) compiler: Don't include source code options in module_info(compile) hipe: Teach hipe to handle slim or stripped BEAM files
2011-11-24compiler: Don't include source code options in module_info(compile)Björn Gustavsson
As far as I know, the purpose of the compiler options included in Mod:module_info(compile) has never been documented. An educated guess is that they are there in case you want to re-compile the module with the same options, and also to aid in debugging when you need to know how a module was compiled. In neither case is there any need to include options given in the source itself in options included in Mod:module_info(compile). Including those options will only waste memory. Therefore, only include in the BEAM file the options that were given to compile:file/2.
2011-11-24hipe: Teach hipe to handle slim or stripped BEAM filesBjörn Gustavsson
2011-11-24sys_expand_pmod: Handle external funs in parameterized modulesBjörn Gustavsson
Starting in ff432e262e65243cbc983fcb002527f8fae8c78b, sys_pre_expand passes external funs through to the downstream passes. It used to translate external funs to a call to erlang:make_fun/3. Therefore, we will now need to handle external funs in sys_expand_pmod. Noticed-by: Stavros Aronis
2011-11-07EEP-23: Allow variables in fun M:F/ABjörn Gustavsson
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
2011-11-02Test calling a parameterized module within a funBjörn Gustavsson
It is tempting to transform code such as: fun(X) -> M:foo(X) end to: fun M:foo/1 Unfortunately, that transformation is not safe if M happens to be a parameterized module. Add a test case so that we don't attempt to do such an optimization in the future.
2011-10-13Allow noncharacter code points in unicode encoding and decodingBjörn Gustavsson
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
2011-09-22Merge branch 'dev' into majorHenrik Nord
2011-09-22Merge branch 'hl/beam_disasm-no_attri_chunk' into devHenrik Nord
* hl/beam_disasm-no_attri_chunk: beam_disasm: Handle stripped BEAM files OTP-9571
2011-09-21beam_disasm: Handle stripped BEAM filesHaitao Li
beam_disasm:file/1 would crash if asked to disassemble a stripped BEAM file without an "Attr" chunk.
2011-09-13Merge branch 'dev' into majorHenrik Nord
Conflicts: lib/asn1/doc/src/asn1ct.xml
2011-09-08Do not write beam file if Werr and warnings /= []Tuncer Ayaz
2011-08-18compiler: Add no_line_info for suppressing line/1 instructionsBjörn Gustavsson
Also update the r12 and r13 options so that they imply no_line_info.
2011-08-16emulator: Add a fourth element in exception stacktracesBjörn Gustavsson
This commit is a preparation for introducing location information (filename/line number) in stacktraces in exceptions. Currently a stack trace looks like: [{Mod1,Function1,Arity1}, . . . {ModN,FunctionN,ArityN}] Add a forth element to each tuple that can be used indication the filename and line number of the source file: [{Mod1,Function1,Arity1,Location1}, . . . {ModN,FunctionN,ArityN,LocationN}] In this commit, the fourth element will just be an empty list, and we will change all code that look at or manipulate stacktraces.
2011-08-16compiler: Generate line instructionsBjörn Gustavsson
2011-08-16compiler tests: Add a test for constants in guardsBjörn Gustavsson
2011-04-12bs_match_SUITE: Improve coverage of beam_bsmBjörn Gustavsson
2011-04-12match_SUITE: Cover a clause in beam_dead:forward/4Björn Gustavsson
2011-04-12record_SUITE: Cover optimization of is_record/3 in beam_typeBjörn Gustavsson
Since the introduction of improved record optimizations in 1858cb81391d2bce29b4b7620574ca60128cebf7 and 470c91d43eae54f63661645acbce4b92d73287cc, the optimization of a is_record/3 call with a known correct type in beam_type:simplify_basic_1/3 has not been covered.
2011-04-12compiler tests: Reinstate ?MODULE macro in calls to test_lib:recompile/1Björn Gustavsson
In 3d0f4a3085f11389e5b22d10f96f0cbf08c9337f (an update to conform with common_test), in all test_lib:recompile(?MODULE) calls, ?MODULE was changed to the actual name of the module. That would cause test_lib:recompile/1 to compile the module with the incorrect compiler options in cloned modules such as record_no_opt_SUITE, causing worse coverage.
2011-03-30Merge branch 'hw/call-chmod-without-f' into devHenrik Nord
* hw/call-chmod-without-f: Call chmod without the "-f" flag Conflicts: erts/emulator/test/Makefile lib/asn1/test/Makefile lib/crypto/test/Makefile lib/debugger/test/Makefile lib/docbuilder/test/Makefile lib/edoc/test/Makefile lib/erl_interface/test/Makefile lib/inviso/test/Makefile lib/parsetools/test/Makefile lib/percept/test/Makefile lib/ssl/test/Makefile lib/syntax_tools/test/Makefile lib/test_server/test/Makefile lib/tools/test/Makefile OTP-9170
2011-03-25sys_core_fold: Eliminate incorrect warningBjörn Gustavsson
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
2011-03-23v3_core: Fix variable incorrectly unbound after binary matchBjörn Gustavsson
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
2011-03-11Update copyright yearsBjörn-Egil Dahlberg