aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/test/guard_SUITE.erl
AgeCommit message (Collapse)Author
2015-06-18Change license text to APLv2Bruce Yinhe
2015-04-30compiler: Use module erl_annoHans Bolinder
2015-04-22test suites: Unload modules compiled from .core or .SBjörn Gustavsson
The .core or .S files that are compiled in the test cases may lack module_info/0,1 functions, which will cause problems if we (for example) try to run eprof later. To avoid that problem, unload each module directly after testing it.
2015-03-09beam_type: Use the complete register map when calculating livenessBjörn Gustavsson
When calculating the number of live registers for allocation instruction, it is not always safe to start with the number of live registers at the start of the block. We will need to use the register map to know whether there are any holes (dead registers) that are not subsequently filled. If the allocation instruction already has a number of live registers calculated, there is nothing to be gained by raising it.
2015-01-26Speed up running of compiler test suites in coverage modeBjörn Gustavsson
I have spent too much time lately waiting for 'cover' to finish, so now its time to optimize the running time of the tests suite in coverage mode. Basically, when 'cover' is running, the test suites would not run any tests in parallel. The reason is that using too many parallel processes when running 'cover' would be slower than running them sequentially. But those measurements were made several years ago, and many improvements have been made to improve the parallelism of the run-time system. Experimenting with the test_lib:p_run/2 function, I found that increasing the number of parallel processes would speed up the self_compile tests cases in compilation_SUITE. The difference between using 3 processes or 4 processes was slight, though, so it seems that we should not use more than 4 processes when running 'cover'. We don't want to change test_lib:parallel/0, because there is no way to limit the number of test cases that will be run in parallel by common_test. However, there as test suites (such as andor_SUITE) that don't invoke the compiler at run-time. We can run the cases in such test suites in parallel even if 'cover' is running.
2015-01-23Merge branch 'egil/fix-maps-compiler-coverage/OTP-12425'Björn-Egil Dahlberg
* egil/fix-maps-compiler-coverage/OTP-12425: compiler: Rename util function to adhere to name policy compiler: Remove get_map_elements label check in blocks compiler: Remove unnecassary guard for get_map_elements compiler: Remove dead code in beam_flatten compiler: Increase Maps code coverage
2015-01-16Merge branch 'maint'Björn Gustavsson
* maint: Update primary bootstrap beam_bool: Correct live calculation for GC BIFs beam_bool: Correct indentation for try...catch sys_core_fold: Correct optimization of 'case' Conflicts: bootstrap/bin/start.boot bootstrap/bin/start_clean.boot bootstrap/lib/compiler/ebin/beam_asm.beam bootstrap/lib/stdlib/ebin/io_lib_pretty.beam
2015-01-14beam_bool: Correct live calculation for GC BIFsBjörn Gustavsson
When optimizing boolean expressions, it is not always possible to find a number of live registers for a GC BIF that both preserves all source registers that will be tested and at the same time does not include registers that are not initialized. As currently implemented, we have incomplete information about the register calculated from the free variables. Some registers are marked as "reserved". Reserved registers means that we don't know anything about them; they may or may not be initialized. As a conservative correction (suitable for a maintenance release), we will abort the optimization if we find any reserved registers when calculating the number of live registers. We will not attempt to improve the information about the registers in this commit. By examining the coverage when running the existing compiler test suite we find that the optimization is aborted 15 times (before adding any new test cases). To put that in perspective, the optimization is successfully applied 4927 times, and aborted for other reasons 547 times. Reported-by: Ulf Norell Reported-by: Anthony Ramine
2015-01-09compiler: Increase Maps code coverageBjörn-Egil Dahlberg
This commit covers 'split_block_label_used' in the beam_bool pass for Maps.
2015-01-09beam_dead: Optimize branches from relational conditionalsBjörn Gustavsson
The BEAM compiler translates code such as: is_hex_digit(D) when $0 =< D, D =< $9 -> true; is_hex_digit(D) when $a =< D, D =< $z -> true; is_hex_digit(D) when $A =< D, D =< $Z -> true; is_hex_digit(_) -> false. to something like this: L0: test is_ge L1 {x,0} 48 test is_ge L1 57 {x,0} move true {x,0} return. L1: test is_ge L2 {x,0} 97 test is_ge L2 122 {x,0} move true {x,0} return L2: test is_ge L3 {x,0} 65 test is_ge L3 90 {x,0} move true {x,0} return L3: move false {x,0} return We can see that tests will be repeated even if they cannot possibly succeed. For instance, if we pass in {x,0} equal to 32, the first test that {x,0} is greater than or equal to 48 at L0 will fail. The control will transfer to L1, where it will be tested whether {x,0} is greater than 97. That test will fail and control will pass to L2, where again the test will fail. The compiler can do better by short-circuiting repeating tests: L0: test is_ge L3 {x,0} 48 test is_ge L1 57 {x,0} move true {x,0} return. L1: test is_ge L2 {x,0} 97 test is_ge L3 122 {x,0} move true {x,0} return L2: test is_ge L3 {x,0} 65 test is_ge L3 90 {x,0} move true {x,0} return L3: move false {x,0} return
2014-03-05Merge branch 'nox/compiler/beam_bool-bad-protected'Björn Gustavsson
* nox/compiler/beam_bool-bad-protected: Properly detect nonboolean protected expressions in beam_bool
2014-03-04Properly detect nonboolean protected expressions in beam_boolAnthony Ramine
Silly code such as the following could make the compiler crash: f() when erlang:float(self()); true -> ok. Reported-by: Ulf Norell
2014-03-03Do not mark all calls to erlang:is_function/2 as safeAnthony Ramine
Calls to erlang:is_function/2 where the second is not a literal nonnegative integer can crash at runtime and thus can't be marked as safe.
2013-08-15Fix compiler crash for 'B and B' guardBjörn Gustavsson
2013-01-25Update copyright yearsBjörn-Egil Dahlberg
2012-10-23compiler: Run testcases in parallelBjörn Gustavsson
Run testcases in parallel will make the test suite run slightly faster. Another reason for this change is that we want more testing of parallel testcase support in common_test.
2011-08-16compiler tests: Add a test for constants in guardsBjörn Gustavsson
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-02-23compiler: Eliminate some warningsBjörn Gustavsson
2011-02-17Rename Suite Callback to Common Test HookLukas Larsson
2011-02-17Fix formatting for compilerLukas Larsson
2011-02-17Add init_per_suite and end_per_suiteLukas Larsson
2011-02-17Add ts_install_scb to suite/0Lukas Larsson
2011-02-17Update compiler tests to conform with common_test standardLukas Larsson
2010-06-02Teach erl_lint to better override BIFs with local functions and importsPatrik Nyblom
Added only a few testcases in compiler:error_SUITE and guard_SUITE The new behaviour of warnings and errors when overriding autoimported BIF's: Bifs that were autoimported before R14 are dangerous because old code using them and overriding them in exports can start behaving differently. For newly added autoimports this can't happen to the new code that wants to (or dont want to) use them, why only warnings are added for the BIFs autoimported after the compilator change. Errors are issued only for code that could have worked in one way in R13 and now will behave in a different way. If overriding autoimport with local function: - if explicit -compile directive supresses autoimport -> no message else - if called from inside module - if pre R14 autoimported bif -> error else -> warning else -> no message If overriding autoimport with import directive - if explicit -compile directive supresses autoimport -> no message else (regardless of actual usage) - if pre R14 autoimported bif -> error else -> warning Calls of local functions or imports overriding autoimported functions (either post R14 or by using explicit -compile supressions of autoimport) always goes to the local function or the imported. The compileation errors are added to not let code like this silently and disastrously change its semantic (probably to an infinite loop) between R13 and R14: ---------- -module(m). -export([length/1]). length(X) -> ... Y = length(Z), .... ---------- The user has to select if he/she wants to call length in 'erlang' explicitly or if the overriding semantics is desired, in which case the -compile directive has to be used. -compile({no_auto_import,[F/A]}). Is added to allow to override the autoimports so that code gets unanbiguous. The directive will remove an autoimport even if there is no local function or import overriding, because any other behaviour would be inconsistent and confusing. record_info and module_info can never be overridden.
2010-05-17Add guard BIFs binary_part/2,3Patrik Nyblom
Add the gc_bif's to the VM. Add infrastructure for gc_bif's (guard bifs that can gc) with two and. three arguments in VM (loader and VM). Add compiler support for gc_bif with three arguments. Add compiler (and interpreter) support for new guard BIFs. Add testcases for new guard BIFs in compiler and emulator.
2010-04-01Merge branch 'bg/compiler-inliner' into devErlang/OTP
* bg/compiler-inliner: pmod_SUITE: Again test inlining parameterized modules compiler tests: Cope with missing args in function_clause for native code compiler tests: Compile a few more modules with 'inline' Consistently rewrite an inlined function_clause exception to case_clause compiler tests: Test the 'inline' option better compiler: Suppress bs_context_to_binary/1 for a literal operand compiler: Fix binary matching bug in the inliner sys_core_inline: Don't generated multiple compiler_generated annos OTP-8552 bg/compiler-inliner Several problems in the inliner have been fixed.
2010-03-26compiler tests: Compile a few more modules with 'inline'Björn Gustavsson
Since a function_clause exception in an inlined function will be changed to a case_clause exception, we must test for both.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP