| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
and some tests that the HiPE compiler is not causing trouble
|
|
|
|
Also, some of the branches were testing sizes in bits against a constant
?MAX_BINSIZE, which was in bytes. The signed comparisons masked this
mistake. These branches have been removed since all sizes in bits that
fit in a machine word are valid binary sizes.
Finally, a test that reproduces the issue was added to bs_construct,
along with a test for one of the cases (bs_init<0>(...)) when the test
against ?MAX_BINSIZE must be changed to unsigned rather than removed.
|
|
|
|
The HiPE compiler was leaking exceptions out of guards involving
binaries with `strange' arithmetic in them. Fixed by the set of
changes in this pull request.
|
|
Some more cases (taken from the BEAM bs_construct suite) that used to
show different behaviour than BEAM when compiled to native code were
included in the appropriate test file of the HiPE test suite.
|
|
* kostis/hipe-bs-match-huge-bin:
Fix matching with huge binaries
Compile without errors for exported variables
OTP-13092
|
|
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.
|
|
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.
|
|
|
|
* 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
|
|
|
|
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.
|
|
|
|
|
|
Change the maps_guard_fun test to accept the HiPE trace format.
|
|
|
|
|
|
|
|
|
|
|
|
Create tests for the HiPE native code compiler. This is the first
part of the effort and contains tests that check that the native
code produced by the HiPE compiler for binaries and bitstrings is
OK and behaves similarly to the code produced by the BEAM compiler.
|
|
|
|
The reason for this is that if you are running a system with native
compiled code, then you will have major problems with soft upgrade
and the only reasonable way to go is to restart your emulator.
Currently there is no instruction that will force ONLY a restart of
the emulator, so the solution would be to hand write a relup with
only a restart_emulator instruction. By letting hipe.appup be empty,
systools will complain and not generate a relup - which should
indicate that you might have to write your relup by hand.
|
|
Add the mentioned test suites for *all* library and touched
non-library applications.
|
