| Age | Commit message (Collapse) | Author |
|---|
|
Literal maps could cause dialyzer to crash when pretty printing the results.
Reported-by: Chris McGrath <[email protected]>
|
|
In commit f667931e2905797ffab63e224e56eaf07f77178a the core format changed
for map pairs. Let dialyzer and hipe pretty printing of maps also adhere to
those changes.
An Erlang map update, M#{foo := 1, bar => 2} will now be printed as:
~{ 'foo' := 1, 'bar' => 2 | M }~
|
|
The code generated by the HiPE compiler for pattern matching with
UTF binaries was such that sometimes THE_NON_VALUE was stored in
the roots followed by the garbage collector. This was not an issue
for the vanilla native code compiler, but was problematic for the
ErLLVM back-end.
Fix the issue by not storing THE_NON_VALUE in the live roots. An
alternative fix would be to change the code of the garbage collector.
With this fix, there are no more (known) failing test cases for the
ErLLVM back-end (at least on x86_64 with LLVM 3.5, which is the
configuation regularly tested). Thanks to @margnus1 for the fix.
|
|
|
|
|
|
|
|
|
|
|
|
- A test for proper handling of negative numbers in binary search
key tables
- A test for HiPE's ICode range analysis
|
|
|
|
|
|
Take out extraneous spaces at the end of lines.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
and some tests that the HiPE compiler is not causing trouble
|
|
|
|
=== OTP-18.2 ===
Changed Applications:
- asn1-4.0.1
- common_test-1.11.1
- compiler-6.0.2
- crypto-3.6.2
- dialyzer-2.8.2
- diameter-1.11.1
- erl_docgen-0.4.1
- erl_interface-3.8.1
- erts-7.2
- eunit-2.2.12
- hipe-3.14
- inets-6.1
- jinterface-1.6.1
- kernel-4.1.1
- observer-2.1.1
- parsetools-2.1.1
- public_key-1.1
- runtime_tools-1.9.2
- sasl-2.6.1
- snmp-5.2.1
- ssh-4.2
- ssl-7.2
- stdlib-2.7
- test_server-3.9.1
- tools-2.8.2
- typer-0.9.10
- wx-1.6
- xmerl-1.3.9
Unchanged Applications:
- cosEvent-2.2
- cosEventDomain-1.2
- cosFileTransfer-1.2
- cosNotification-1.2
- cosProperty-1.2
- cosTime-1.2
- cosTransactions-1.3
- debugger-4.1.1
- edoc-0.7.17
- eldap-1.2
- et-1.5.1
- gs-1.6
- ic-4.4
- megaco-3.18
- mnesia-4.13.2
- odbc-2.11.1
- orber-3.8
- os_mon-2.4
- ose-1.1
- otp_mibs-1.1
- percept-0.8.11
- reltool-0.7
- syntax_tools-1.7
- webtool-0.9
Conflicts:
OTP_VERSION
erts/vsn.mk
|
|
|
|
|
|
|
|
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.
|
|
This allows us to compile bs_match_int_SUITE with HiPE without a
system_limit crash.
|
|
Bugs were fixed in
hipe_rtl_binary_match:{first_part/3,make_size/3,set_high/1} in commit
5aea81c49, but it turns out these had been copy-pasted verbatim into
hipe_rtl_binary_construct, where they were causing further bugs. They
have now moved to hipe_rtl_binary, from where they are included by the
other two modules.
Furthermore, first_part/3 (reamed get_word_integer/3, since it loads
integers that fits into an unsigned word), and make_size/3 now accepts a
fourth argument to distinguish too large arguments (which should cause a
system_limit exception) from negative or non-integral arguments.
The use of first_part/3 (get_word_integer/3) from 5aea81c49 in
hipe_rtl_binary_construct now allows several binary construction
instructions to accept bignum sizes, as they were supposed to.
Additionally, calls to
hipe_rtl_binary_construct:check_and_untag_fixnum/3 were replaced with
get_word_integer/4 since all of them were also supposed to accept
sufficiently small bignums, but didn't, and check_and_untag_fixnum/3 was
essentially identical to first_part/3 anyway.
HiPE is now capable of passing bs_construct_SUITE completely unmodified.
|
|
Expressions like <<0:(fun(X)->X end(anka))>> would fail with 'badarith'
in HiPE, but 'badarg' in BEAM.
hipe_beam_to_icode was attempting to optimise the amount of code
generated by letting the arithmetic error propagate instead of
catching it. However, since it was emitting a block to throw 'badarg' in
that case anyway, we can just reuse it to achieve just as compact code
that behaves exactly like BEAM.
|
|
hipe_rtl_arith is only used by hipe_rtl_ssa_const_prop, which applies it
to any RTL, including RTL where the intent is to do unsigned math. Since
signed and unsigned operations produce the same 2's complement result,
this change is harmless.
On 32-bit architectures it caused HiPE crashes when compiling code like
<<0:((1 bsl 32)-1)>>, because the size of the field is too large to fit
in a signed integer.
|
|
The unit size field was previously completely discarded when lowering
this instruction from BEAM to Icode.
This feature was previously missing and expressions such as <<0,
<<1:1>>/binary>> would succeed construction when compiled with HiPE.
|
|
This feature was previously missing and expressions such as
<<<<1:1>>/binary>> would succeed construction when compiled with HiPE.
A primop is_divisible is introduced to handle the case when the unit
size is not a power of two.
|
|
Relying on double-precision floating-point arithmetic to compute the
log2 of an integer up to 64 bits long leads to rounding errors.
|
|
* lucafavatella/dialyzer-remote-type:
Delete remote types-related dead code in erl_types
OTP-13104
|
|
|
|
* kostis/hipe-bs-match-huge-bin:
Fix matching with huge binaries
Compile without errors for exported variables
OTP-13092
|
|
* maint:
[erl_docgen] Correct documentation
[dialyzer] Correct documentation
[hipe] Correct documentation
[test_server] Correct documentation
[tools] Correct documentation
[erts] Correct documentation
[stdlib] Correct documentation
[kernel] Correct documentation
Conflicts:
lib/stdlib/doc/src/erl_scan.xml
|
|
Fix mistakes found by 'xmllint'.
|
|
|
|
|
|
* lucafavatella/dialyzer-fun-literal-arity:
Teach Dialyzer arity of funs with literal arity
OTP-13068
|
|
Code became dead in 854ee8b.
|
|
|
|
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.
|
|
The bulk of the changes concerns cleanups and code refactorings concerning
record constructions that assigned 'undefined' to record fields whose type
did not contain this value. See commit 8ce35b2.
While at it, some new type definitions were introduced and type names were
used instead of record type notation. Minor code cleaups were also done.
|
|
Background
-----------
In record fields with a type declaration but without an initializer, the
Erlang parser inserted automatically the singleton type 'undefined' to
the list of declared types, if that value was not present there.
I.e. the record declaration:
-record(rec, {f1 :: float(),
f2 = 42 :: integer(),
f3 :: some_mod:some_typ()}).
was translated by the parser to:
-record(rec, {f1 :: float() | 'undefined',
f2 = 42 :: integer(),
f3 :: some_mod:some_typ() | 'undefined'}).
The rationale for this was that creation of a "dummy" #rec{} record
should not result in a warning from dialyzer that e.g. the implicit
initialization of the #rec.f1 field violates its type declaration.
Problems
---------
This seemingly innocent action has some unforeseen consequences.
For starters, there is no way for programmers to declare that e.g. only
floats make sense for the f1 field of #rec{} records when there is no
`obvious' default initializer for this field. (This also affects tools
like PropEr that use these declarations produced by the Erlang parser to
generate random instances of records for testing purposes.)
It also means that dialyzer does not warn if e.g. an is_atom/1 test or
something more exotic like an atom_to_list/1 call is performed on the
value of the f1 field.
Similarly, there is no way to extend dialyzer to warn if it finds record
constructions where f1 is not initialized to some float.
Last but not least, it is semantically problematic when the type of the
field is an opaque type: creating a union of an opaque and a structured
type is very problematic for analysis because it fundamentally breaks
the opacity of the term at that point.
Change
-------
To solve these problems the parser will not automatically insert the
'undefined' value anymore; instead the user has the option to choose the
places where this value makes sense (for the field) and where it does
not and insert the | 'undefined' there manually.
Consequences of this change
----------------------------
This change means that dialyzer will issue a warning for all places
where records with uninitialized fields are created and those fields have
a declared type that is incompatible with 'undefined' (e.g. float()).
This warning can be suppressed easily by adding | 'undefined' to the
type of this field. This also adds documentation that the user really
intends to create records where this field is uninitialized.
|
|
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.
|
