aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler
AgeCommit message (Collapse)Author
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-29pmod_SUITE: Again test inlining parameterized modulesBjörn Gustavsson
Commit 91de9d0670c6fe1cff08cefa6e1c396effba47b8 stopped testing inlining of parameterized modules, because of a bug in the inliner.
2010-03-26compiler tests: Cope with missing args in function_clause for native codeBjörn Gustavsson
Native-compiled code generates a different stack trace for function_clause exceptions - instead of the arguments for the function, only the arity is reported. Accept missing arguments if the test suite is native-compiled.
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.
2010-03-26Consistently rewrite an inlined function_clause exception to case_clauseBjörn Gustavsson
A function_clause exception is generated by jumping to a func_info/3 instruction at the beginning of the function. The x registers are assumed to contain the arguments for the function. That means that a func_info/3 instruction copied from another function (or even from the same function if not at the top level) will not work, so it must be replaced with an instruction that generates a case_clause exception. In Core Erlang, a func_info/3 instruction is represented as a the primop match_fail({function_clause,Arg1,...ArgN}). The current mechanism that is supposed to replace the primop match_fail(function_clause) with match_fail(case_clause) will fail to do that in the following circumstances: 1. If the inliner has inlined a function into itself. Fix that by having the inliner clear the function_name annotations on all match_fail primops in functions that are inlined. (To simplify doing that, the annotation is now on the primop node itself and not on the 'function_clause' atom inside it.) 2. If the inliner has rewritten the tuple node in the primop node to a literal (when inlining a function call with literal arguments), v3_kernel would not recognize the match_fail(function_clause) primop and would not rewrite it. Fix it by making v3_kernel smarter. Also simplify the "old" inliner (sys_core_inline) to only clear the function_name annotations instead of rewriting function_clause execptions to case_clause execptions itself.
2010-03-26compiler tests: Test the 'inline' option betterBjörn Gustavsson
Clone some test suites and compile them with the 'inline' option to test inlining more thorughly.
2010-03-26compiler: Suppress bs_context_to_binary/1 for a literal operandBjörn Gustavsson
The inliner can cause illegal uses of the bs_context_to_binary/1 instruction, such as: bs_context_to_binary {literal,"string"} or bs_context_to_binary {integer,1} Remove the bs_context_to_binary/1 instruction if the operand is not a register (it is clearly not needed).
2010-03-26compiler: Fix binary matching bug in the inlinerBjörn Gustavsson
The inliner incorrectly assumes that a literal cannot match a binary in code such as: t() -> bc(<<"string">>). bc(<<A:1,T/bits>>) -> [A|bc(T)]; bc(<<>>) -> []. The bug was introduced when binary literals were introduced.
2010-03-26sys_core_inline: Don't generated multiple compiler_generated annosBjörn Gustavsson
Multiple compiler_generated annotations are harmless, but makes listing files harder to read during debugging.
2010-03-25Merge branch 'bg/compiler-remove-r11-support' into devErlang/OTP
* bg/compiler-remove-r11-support: compiler: Don't support the no_binaries option erts: Don't support the put_string/3 instruction compiler: Don't support the no_constant_pool option compiler: Don't support the r11 option test_server: Don't support communication with R11 nodes binary_SUITE: Don't test bit-level binary roundtrips with R11 nodes erts: Test compatibility of funs with R12 instead of R11 OTP-8531 bg/compiler-remove-r11-support
2010-03-22compiler: Don't support the no_binaries optionBjörn Gustavsson
The no_binaries option terminates the compiler with an error if any bit syntax is used in the module being compiled. (It used to be implied by the removed r11 option.)
2010-03-22erts: Don't support the put_string/3 instructionBjörn Gustavsson
Since R14 does not need to load code that can also be loaded in an R11 run-time system, support for the put_string/3 instruction can be removed.
2010-03-22compiler: Don't support the no_constant_pool optionBjörn Gustavsson
The no_constant_pool option was implied by the r11 option. It turns off the usage of the constant (literal) pool, so that BEAM instructions that use constants can be loaded in an R11 system. Since the r11 option has been removed, there is no need to retain the no_constant_pool option.
2010-03-22compiler: Don't support the r11 optionBjörn Gustavsson
The r11 option was used to generate BEAM modules that could loaded both on both R11 and R12/R13 to facilitate testing that R11 and R13 nodes could communicate with each other. Since R14 is only required to be compatible with R12 and R13 nodes, the r11 option is no longer needed.
2010-03-17compiler: Provide more information if the v3_life pass crashesBjörn Gustavsson
Print the name and arity of the function being compiled if the v3_life compiler pass crashes to facilitate finding out which part of the source code that triggered the problem.
2010-02-19Update release notesBjörn-Egil Dahlberg
2010-02-17OTP-8447 Bit string comprehensions can now be used in parameterizedHans Bolinder
modules. (Thanks to Jebu Ittiachen.)
2010-02-10Merge branch 'ks/compiler' into ccase/r13b04_devErlang/OTP
* ks/compiler: compiler: keep line numbers for attributes compiler Makefile: alphabetize module names compile.erl: eliminate compiler warning
2010-02-10Support the configure option --enable-native-libsKostis Sagonas
2010-02-10compiler: keep line numbers for attributesKostis Sagonas
In the future, we might want to generate warnings for attributes, referring to them with line numbers. sys_pre_expand used to replace line number for attributes with 0. Change sys_pre_expand to retain the real line number. v3_core used to throw away the line numbers. Change v3_core so that it retains the line numbers in annotations. While at it, do some tidying as suggested by tidier.
2010-02-10compiler Makefile: alphabetize module namesKostis Sagonas
2010-02-10compile.erl: eliminate compiler warningKostis Sagonas
2010-02-05OTP-8404: Doc: some corrections and improvements in STDLIBBjörn Gustavsson
2010-01-30compiler: make ignore_native_errors also handle internal hipe errorsBjörn Gustavsson
We must also catch exits, not only errors, since the hipe compilers does an exit/1 if an internal error is found.
2010-01-30Teach the compiler the no_native optionBjörn Gustavsson
Implement the 'no_native' option to disable native-code compilation. If given in a module like this: -compile(no_native). it will override a 'native' option given on the command line.
2010-01-20Merge branch 'cf/compile_warning_as_error' into ccase/r13b04_devErlang/OTP
* cf/compile_warning_as_error: Add option -Werror in erlc(1) compile: add flag warnings_as_errors to treat warnings as errors compile.erl: remove trailing whitespace OTP-8382 The -Werror option for erlc and the compiler option warnings_as_errors will cause warnings to be treated as errors. (Thanks to Christopher Faulet.)
2010-01-19compile: add flag warnings_as_errors to treat warnings as errorsChristopher Faulet
With this flag, warnings are treated as errors, like gcc flag '-Werror'.
2010-01-19compile.erl: remove trailing whitespaceBjörn Gustavsson
2010-01-19Update version numbersBjörn Gustavsson
2010-01-19Merge branch 'bg/compiler-beam_validator' into ccase/r13b04_devErlang/OTP
* bg/compiler-beam_validator: beam_validator: fix incorrect assumptions about GC guard BIFs OTP-8378 In rare circumstances when using garbaging collecting guard BIFs, the validation pass (beam_validator) would signal that the code was unsafe, when it in fact was correct. (Thanks to Kiran Khaladkar.)
2010-01-15beam_validator: fix incorrect assumptions about GC guard BIFsBjörn Gustavsson
The beam_validator pass incorrectly assumes that a GC guard BIF (such as length/1) may first do a garbage collection and then fail. That assumption is not correct (guards BIF only do garbage collection when it is known that the BIF call will succeed), and will cause the compiler to reject valid programs. Modify the beam_validator to assume that if the branch is taken for a gc_bif instruction, all registers are unchanged and no garbage collection has occurred. Also add a comment in the emulator about that assumption.
2009-12-14Merge branch 'bg/on_load' into ccase/r13b04_devErlang/OTP
* bg/on_load: Test on_load functions that don't return 'ok' Change the expected return value for on_load functions OTP-8339 The expected return value for an on_load function has been changed. (See the section about code loading in the Reference manual.)
2009-12-14Merge branch 'bg/compiler-bopt-bug' into ccase/r13b04_devErlang/OTP
* bg/compiler-bopt-bug: beam_bool: Fix generation of code that does not validate Fix crash in beam_bool OTP-8338 Using complex boolean expressions in ifs could cause the compiler to either crash or teminate with an internal error. (Thanks to Simon Cornish.)
2009-12-13Change the expected return value for on_load functionsBjörn Gustavsson
An on_load function is supposed to return 'true' to indicate that the module should be loaded, and 'false' if it should be unloaded. But returning any other term, as well as causing an exception, will also unload the module. Since we don't like boolean values mixed with other values, change the expected return value as follows: * If 'ok' is returned, the module will remain loaded and become callable. * If any other value is returned (or an exception is generated), the module will be unloaded. Also, if the returned value is not an atom, send a warning message to the error_logger (using error_logger:warning_msg/2). The new interpretation of the return value means that an on_load function can now directly return the return value from erlang:load_nif/2.
2009-12-11beam_bool: Fix generation of code that does not validateBjörn Gustavsson
The following code (by Simon Cornish) bad(XDo1, XDo2, Do3) -> Do1 = (XDo1 =/= []), Do2 = (XDo2 =/= []), CH1 = if Do1 == true; Do1 == false,Do2==false,Do3 == blah -> ch1; true -> no end, CH2 = if Do1 == true; Do1 == false,Do2==false,Do3 == xx -> ch2; true -> no end, {CH1,CH2}. is optimized by beam_bool even though the optimization is not safe. The trouble is that an assignment to {y,0} no longer occurs on all paths leading to its use. The bug is in dst_regs/2 which is supposed to return a set of all registers assigned in a code block, but it ignores registers assigned in 'move' instructions. Fix the bug by taking 'move' instructions into account. This change is safe since it can only cause more registers to be added to the MustBeKilled and MustBeUnused sets in ensure_opt_safe/6, which means that it can only cause the optimization to be turned off for code that used to be optimized.
2009-12-10Fix crash in beam_boolBjörn Gustavsson
The following code crashes beam_bool: bad(XDo1, XDo2, Do3) -> Do1 = (XDo1 =/= []), Do2 = (XDo2 =/= []), if Do1 =:= true; Do1 =:= false, Do2 =:= false, Do3 =:= delete -> no end. (Reported by Simon Cornish; minimized by Kostis Sagonas.) For the moment fix the bug in the simplest and safest way possible (basically, instead of crashing just don't do the optimization). In a future major release (e.g. R14), the following improvements could be considered: * In beam_bool, it should be possible to move the Do1 and Do2 expressions to the pre-block and still optimize the expression in the 'if' statement. * In sys_core_fold, it should be possible to eliminate the try/catch around the guard expression in the 'if', because none of the guard tests can actually fail.
2009-12-09compiler: Teach 'slim' to omit compilation infoBjörn Gustavsson
The original intention for the undocumented 'slim' option was to omit non-essential parts of *.beam files to reduce the size of the primary bootstrap. Therefore, debug information and local function information (only used by xref, not by the loader) are omitted, but information about the compilation time and compiler version are still included. Including compilation information is troublesome, however, when committing the bootstrap into a revision control system, because every beam file is guaranteed to be changed every time the bootstrap is updated. Therefore, change the 'slim' option to also omit compilation information.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP