aboutsummaryrefslogtreecommitdiffstats
path: root/lib/hipe
AgeCommit message (Collapse)Author
2015-11-09Merge branch 'kostis/hipe-bs-match-huge-bin' into maintHenrik Nord
* kostis/hipe-bs-match-huge-bin: Fix matching with huge binaries Compile without errors for exported variables OTP-13092
2015-11-04[hipe] Correct documentationHans Bolinder
Fix mistakes found by 'xmllint'.
2015-10-27Merge branch 'lucafavatella/dialyzer-fun-literal-arity' into maintHenrik Nord
* lucafavatella/dialyzer-fun-literal-arity: Teach Dialyzer arity of funs with literal arity OTP-13068
2015-10-12Fix edge case of Size = 0 in bs_put_integerKostis Sagonas
copy_offset_int_big was assuming (Offset + Size - 1) (Tmp9 in the first BB) would not underflow. It was also unconditionally reading and writing the binary even when Size was zero, unlike copy_int_little, which is the only other case of bs_put_integer that does not have a short-circuit on Size = 0. This was causing segfaults when constructing binaries starting with a zero-length integer field, because a logical right shift was used to compute an offset in bytes (which became 0x1fffffffffffffff) to read in the binary. Tests, taken from the emulator bs_construct_SUITE, were also added. The complete credit for the report and the fix goes to Magnus Lång.
2015-10-02Fix matching with huge binariesKostis Sagonas
In certain cases of matching with very big binaries, the HiPE compiler generated code that would fail the match, even in cases that the matching was successful. The problem was more quite noticeable on 32-bit platforms where certain integer quantities would be represented as bignums. Brief summary of changes: * gen_rtl({bs_skip_bits, ...}, ...) could not handle too large constants. Previously the constants were truncated to word size. * hipe_rtl_binary_match:make_size/3 erroneously assumed that the output of first_part/3 would not overflow when multiplied by 8, which is no longer true. To maintain full performance, the overflow test is only performed when BitsVar was a bignum. Thus, the fast path is identical to before. * hipe_rtl_binary_match:set_high/2 was assuming that only bits below bit 27 were ever set in arguments to bs_skip_bits, which is not only false when the arguments are bignums, but also on 64-bit platforms. The commit includes a test taken from the bs_match_bin_SUITE. Most of the credit for finding these HiPE compiler errors and for creating appropriate fixes for them should go to Magnus Lång.
2015-10-02Compile without errors for exported variablesKostis Sagonas
2015-09-21Prepare releaseErlang/OTP
2015-09-16Update application versionsHans Bolinder
2015-09-09dialyzer: Correct the handling of parameters of opaque typesHans Bolinder
Prior to this commit, the fact that parameters of opaque types are expanded differently depending on the current values of limits used during expansion, caused problems later when the types of parameters are used for determining if opaque types are comparable.
2015-09-04dialyzer: Fix erlang:abs/1Hans Bolinder
Fix the range type of erlang:abs/1.
2015-08-31Merge branch 'sverk/hipe-fix-literal-crc' into maintSverker Eriksson
* sverk/hipe-fix-literal-crc: erts,hipe,dialyzer: Fix hipe checkum of target runtime system erts: Change THE_NON_VALUE to not be hard coded in hipe compiler OTP-12962 OTP-12963 OTP-12964
2015-08-31erts,hipe,dialyzer: Fix hipe checkum of target runtime systemSverker Eriksson
Main problem: A faulty HIPE_LITERAL_CRC was not detected by the loader. Strangeness #1: Dialyzer should ask the hipe compiler about the target checksum, not an internal bif. Strangeness #2: The HIPE_SYSTEM_CRC checksum was based on the HIPE_LITERALS_CRC checksum. Solution: New HIPE_ERTS_CHECKSUM which is an bxor of the two (now independent) HIPE_LITERALS_CRC and HIPE_SYSTEM_CRC. HIPE_LITERALS_CRC represents values that are assumed to stay constant for different VM configurations of the same arch, and are therefor hard coded into the hipe compiler. HIPE_SYSTEM_CRC represents values that may differ between VM variants. By default the hipe compiler asks the running VM for this checksum, in order to create beam files for the same running VM. The hipe compiler can be configured (with "make XCOMP=yes ...") to create beam files for another VM variant, in which case HIPE_SYSTEM_CRC is also hard coded. ToDo: Treat all erts properties the same. Either ask the running VM or hard coded into hipe (if XCOMP=yes). This will simplify and reduce the risk of dangerous mismatches. One concern might be the added overhead from more frequent calls to hipe_bifs:get_rts_param.
2015-08-25dialyzer: Optimize expansion of parameters of opaque typesHans Bolinder
Opaque recursive parameters are expanded faster.
2015-08-25dialyzer: Optimize the expansion of parameterized types somewhatHans Bolinder
Expand parameters when needed only. The opaqueness is removed from types expanded to any().
2015-08-25dialyzer: Improve the handling of recursive parameterized opaque typesHans Bolinder
2015-08-25dialyzer: Generalize an argument of erl_types:t_from_form()Hans Bolinder
Add more information about the caller of t_from_form(). Instead of just the module, also provide name of the type, spec, or record where the type form resides.
2015-08-24erts: Change THE_NON_VALUE to not be hard coded in hipe compilerSverker Eriksson
Instead ask running VM for the value of THE_NON_VALUE, which is different between opt and debug VM. Same hipe compiler can now compile for both opt and debug VM.
2015-08-21hipe/dialyzer: Fix a bug concerning opaque types and keydelete/3Hans Bolinder
Thanks to ILYA Khlopotov for pointing the bug out.
2015-08-19dialyzer: Fix a bug concerning parameterized opaque typesHans Bolinder
The example is provided by James Fish in http://erlang.org/pipermail/erlang-questions/2014-December/082204.html. Note that warnings with text such as "the _ variable breaks opaqueness" are still possible.
2015-07-11Teach Dialyzer arity of funs with literal arityLuca Favatella
Re-insert logic for `erlang:make_fun/3` in `erl_bif_types`. It had been removed in bd941f5 while type spec-ing `erlang.erl`. Type spec in `erlang.erl` cannot express arity of returned fun based on value of argument hence re-introducing logic in `erl_bif_types`. Re-definition of logic in `erl_bif_types` follows approach in 9d870a0.
2015-06-23Prepare releaseErlang/OTP
2015-06-22Merge branch 'bruce/change-license'Bruce Yinhe
OTP-12845 * bruce/change-license: fix errors caused by changed line numbers Change license text to APLv2
2015-06-22Merge branch 'kostis/hipe-no-dial-warnings'Henrik Nord
* kostis/hipe-no-dial-warnings: Eliminate a dialyzer warning Simplify handling of o2 and o3 option expansion
2015-06-18Change license text to APLv2Bruce Yinhe
2015-06-15dialyzer: Fix a minor bug concerning opaque typesHans Bolinder
The test t_is_none() does not check for opaque types (and this is most likely how it should be), why t_opaque() should never be called with none().
2015-06-15dialyzer: Modify warning for comparison of opaque typesHans Bolinder
Comparing two operands for (in)equality is allowed if both operands are of the same unknown opaque type. Since OTP 17, there is a warning if the types of the operands have nothing in common (this cannot happen before OTP 17). However, the warning says there is a test between opaque types, which is wrong. The warning now states that the comparison cannot evaluate to 'true', which is more consistent.
2015-06-15dialyzer: Modify the handling of parametrized opaque typesHans Bolinder
In OTP 17 it is possible to mix types such as dict:dict() and dict:dict(_, _) outside of the dict module (and similarly for some other opaque types in STDLIB), but the results are unfortunately possibly invalid warnings in users' code. In OTP 18 parameterized opaque types with the same name but with different number of parameters are no longer compatible when seen from outside of the module where the types are declared. The types in STDLIB have been updated accordingly; for instance -opaque dict() :: dict(_, _). has been replaced by -type dict() :: dict(_, _).
2015-06-15dialyzer: Fix a bug in the expansion of formsHans Bolinder
The check that a modified type of a field is a subtype of the declared type has been moved outside of the expansion of forms to avoid loops.
2015-06-13Eliminate a dialyzer warningKostis Sagonas
For quite some time now, this module generated a (quite harmless) dialyzer warning. Comment out a clause which was actually unreachable. While at it, do some small code refactorings here and there.
2015-06-13Simplify handling of o2 and o3 option expansionKostis Sagonas
A recent rewrite of some code in this file (commit 355f4b5) exposed some dialyzer warnings of some code which is unreachable. Indeed, checking whether one executes on an unsupported architecture when expanding the 'o2' and 'o3' hipe compiler options is unnecessary because that check is performed in the expansion of the 'o1' option anyway. While at it, simplified the code a bit not to have a very long case clause.
2015-06-10Merge branch 'richcarl/avoid-try-native-load'Henrik Nord
* richcarl/avoid-try-native-load: Update list of funcalls in kernel code_SUITE Move architecture knowledge out of hipe loader Avoid repeated calls to system_info in hipe loader Avoid exception overhead if HiPE is disabled HiPE help shouldn't modify the calling process OTP-12816
2015-06-04HiPE help shouldn't modify the calling processRichard Carlsson
2015-06-03Merge branch 'kostis/llvm-now'Henrik Nord
* kostis/llvm-now: Replace call to erlang:now() with appropriate call to 18.0 BIF
2015-05-29Merge branch 'kostis/cerl_pmatch'Zandra Hird
* kostis/cerl_pmatch: Allow use of complete interface of cerl_pmatch module OTP-12794
2015-05-29Merge branch 'legoscia/dialyzer/cache-hipe-binaries/OTP-12779'Björn Gustavsson
* legoscia/dialyzer/cache-hipe-binaries/OTP-12779: Dialyzer to cache results of HiPE compilation Change hipe_bifs:system_crc/1 to hipe_bifs:system_crc/0
2015-05-27Change hipe_bifs:system_crc/1 to hipe_bifs:system_crc/0Magnus Henoch
The macro HIPE_SYSTEM_CRC used to contain a hidden cookie from the VM that generated hipe_literals.hrl. This means that BEAM files containing that macro would be tied to a particular version of the VM. Change hipe_bifs:system_crc such that it doesn't require a hidden cookie to return the desired value.
2015-05-27Replace call to erlang:now() with appropriate call to 18.0 BIFKostis Sagonas
2015-05-27Update application versionsHans Bolinder
2015-05-25Update runtime_dependencies in application resource filesHans Bolinder
Applications that use the new erl_anno module are depending on STDLIB 2.5. Note that CosNotification, Megaco, SNMP, Xmerl, and Parsetools use the erl_anno module via the Yecc parsers only (the header file in lib/parsetools/include/yeccpre.hrl calls the erl_anno module). HiPE does not call the erl_anno module, but uses an exported type. We have chosen to make HiPE dependent on the erl_anno module.
2015-05-13Revert "Prepare release"Henrik Nord
This reverts commit e09dd66dc4d89c62ddfd8c19791f9678d5d787c6.
2015-05-12Prepare releaseErlang/OTP
2015-05-12Allow use of complete interface of cerl_pmatch moduleKostis Sagonas
The cerl_pmatch module performs pattern matching compilation at the level of Core Erlang. Functions that were not needed by the HiPE compiler were ifdef-ed out. However, these functions may come handy to other users; in particular a new testing tool currently under development needs access to these functions. While at it, added specs for these exported functions and also strengthened the spec of another one.
2015-05-08dialyzer: document the type identifier()Hans Bolinder
2015-05-06Merge branch 'sverk/hipe_match_wbin/OTP-12667'Sverker Eriksson
* sverk/hipe_match_wbin/OTP-12667: erts: Add debug assertions for match state sanity hipe: Add test for matching of writable binary erts,hipe: Optimize away calls to emasculate_binary erts,hipe: Fix bug in binary matching of writable binary Conflicts: erts/emulator/hipe/hipe_bif0.c
2015-04-30hipe: Use module erl_annoHans Bolinder
2015-04-29hipe: Add test for matching of writable binarySverker Eriksson
2015-04-21erts,hipe: Optimize away calls to emasculate_binarySverker Eriksson
Only call emasculate_binary if ProcBin.flags is set, which means it's a writable binary.
2015-04-21hipe: Fix a bug in the handling of opaque typesHans Bolinder
An opaque type ?opaque(_) was put in a list where #opaque{} was expected.
2015-04-20erts,hipe: Fix bug in binary matching of writable binarySverker Eriksson
Seen symptom: Hipe compiled code with <<C/utf8, ...>> = Bin does sometimes not match even though Bin contains a valid utf8 character. There might be other possible binary matching symptoms, as the problem is not utf8 specific. Problem: A writable binary was not "emasculated" when the matching started (as it should) by the hipe compiled code. Fix: Add a new primop emasculate_binary(Bin) that is called when a matchstate is created. ToDo: There are probably room for optimization. For example only call emasculate_binary if ProcBin.flags is set.
2015-04-15Raise more descriptive error messages for failed map operationsBjörn Gustavsson
According to EEP-43 for maps, a 'badmap' exception should be generated when an attempt is made to update non-map term such as: <<>>#{a=>42} That was not implemented in the OTP 17. José Valim suggested that we should take the opportunity to improve the errors coming from map operations: http://erlang.org/pipermail/erlang-questions/2015-February/083588.html This commit implement better errors from map operations similar to his suggestion. When a map update operation (Map#{...}) or a BIF that expects a map is given a non-map term, the exception will be: {badmap,Term} This kind of exception is similar to the {badfun,Term} exception from operations that expect a fun. When a map operation requires a key that is not present in a map, the following exception will be raised: {badkey,Key} José Valim suggested that the exception should be {badkey,Key,Map}. We decided not to do that because the map could potentially be huge and cause problems if the error propagated through links to other processes. For BIFs, it could be argued that the exceptions could be simply 'badmap' and 'badkey', because the bad map and bad key can be found in the argument list for the BIF in the stack backtrace. However, for the map update operation (Map#{...}), the bad map or bad key will not be included in the stack backtrace, so that information must be included in the exception reason itself. For consistency, the BIFs should raise the same exceptions as update operation. If more than one key is missing, it is undefined which of keys that will be reported in the {badkey,Key} exception.