| Age | Commit message (Collapse) | Author |
|---|
|
https://bugs.erlang.org/browse/ERL-1026
|
|
The compiler would crash when compiling the following code:
do(Acc) ->
receive
{Pid, abc} ->
ok;
{Pid, []} ->
ok;
{Pid, _Res} ->
exit(_Res)
end,
do([Pid | Acc]).
The last clause that always raises an exception would confuse the
compiler so that it would think that the `receive` statement was at the
end of the function and it would generate incorrect code for the `do/1`
call following the `receive`.
https://bugs.erlang.org/browse/ERL-1022
|
|
* bjorn/compiler/fix-stack-init/ERL-1017/OTP-15968:
Ensure that the stack slots are initialized when matching maps
|
|
When matching a map, the compiler could fail to generate code that
would initialize all stack slots (Y registers) properly. Here is a
general outline of code that *could* cause this problem:
foo(Key, Map) ->
Res = case Map of
#{Key := Val} ->
%% Do something with Val here.
.
.
.
#{} ->
[]
end,
%% The stack slot for Val might not have been initialized
%% here if the key was not present in the map.
.
.
.
%% Use Res.
.
.
.
The code generator would wrongly assume that the map matching would
always initialize the stack slot, and if nothing else happened to
force that stack slot to be initialized, it would remain
uninitialized, which would likely crash the runtime system at the next
garbage collection.
`beam_validator` is supposed to find these kind of problems, but a bug
in `beam_validator` prevented it from detecting this problem.
https://bugs.erlang.org/browse/ERL-1017
|
|
into maint
* john/compiler/fix-delayed-type-inference/OTP-15954/ERL-995:
beam_validator: Values referenced by other values must be merged
|
|
https://github.com/bjorng/otp into maint
OTP-15970
* 'bjorn/compiler/length-misuse/ERL-1013' of https://github.com/bjorng/otp:
Eliminate a crash in the type optimizer pass
|
|
https://github.com/bjorng/otp into maint
OTP-15969
* 'bjorn/compiler/fix-no_type_opt/ERL-997' of https://github.com/bjorng/otp:
Fix compiler crash when compiling with +no_type_opt
|
|
* bjorn/compiler/fix-unsafe-sharing/OTP-15963:
Fix unsafe code sharing
|
|
If the `no_type_opt` option was given, the compiler would crash when
attempting to compile containing with a `try`...`after` construct,
such as this code:
foo() ->
try
make_ref()
after
ok
end.
To avoid having this bug re-appear, test the `no_type_opt` option
in the test suites.
https://bugs.erlang.org/browse/ERL-997
|
|
https://bugs.erlang.org/browse/ERL-1013
|
|
|
|
This is a more proper fix for ERIERL-348. We used to think that
we wouldn't need to update the type of a variable that's no
longer referenced by a register ("dead value"), but the attached
test case pokes a hole in that assumption.
To summarize, the result of '=:='/2 is kept alive longer than one
of its arguments, which gets pruned in a state merge leaving us
with nothing to work on when we finally compare the result. This is
fine for most operations since there's no point in (say) updating
the size of a tuple we can no longer reach, but '=:='/2 updates
the types of both arguments and we risk missing out on important
information when either of them is gone.
This commit fixes the problem by merging all values that are
*reachable* from a register, rather than just those that *exist*
in a register, ensuring that all values stay around at least as
long as they're needed.
|
|
into maint
* john/compiler/fix-bad-try_catch-recv-fix/OTP-15953/ERL-999:
compiler: Fix compiler crash introduced by OTP-15952
|
|
An assertion in code generation would fail when the common exit
block was ?BADARG_BLOCK, as some operations expect to always "fail"
directly to that block (= throw an exception) and we had inserted
a dummy block in between.
Other operations could also get funny fail labels, jumping to
blocks that immediately jumped to {f,0}, but these were all cleaned
up by beam_jump, sweeping the bug under the rug.
|
|
maint-22
* john/compiler/fix-fail-path-exceptions-bsm/OTP-15946:
beam_ssa_bsm: Leave ?BADARG_BLOCK alone when cloning fail path
|
|
* john/compiler/fix-unsafe-tuple_size-opt/OTP-15945:
beam_ssa_opt: Do not apply tuple_size optimization outside guards
|
|
* john/compiler/fix-try_catch-receives/OTP-15952:
compiler: Fix broken 'receive' in try/catch blocks
|
|
This fix is rather ugly and tacked-on, but I'm not comfortable
refactoring the pass in an emergency patch.
|
|
* john/compiler/fix-fail-path-exceptions-bsm/OTP-15946:
beam_ssa_bsm: Leave ?BADARG_BLOCK alone when cloning fail path
|
|
* john/compiler/fix-unsafe-tuple_size-opt/OTP-15945:
beam_ssa_opt: Do not apply tuple_size optimization outside guards
|
|
|
|
Rewriting `tuple_size` to `is_tuple` + `tuple_size` will cause it
not to throw an exception, either crashing the compiler or the
emulator when the code runs.
|
|
* john/compiler/fix-bad-bitstring-type-opt/OTP-15872:
beam_ssa_type: Fix incorrect bitstring unit determination
|
|
into maint
* john/erts/fix-bad-get_tuple_element-opt/OTP-15871/ERIERL-374:
erts: Fix bad loader optimization of get_tuple_element
|
|
* john/compiler/fix-bad-bitstring-type-opt/OTP-15872:
beam_ssa_type: Fix incorrect bitstring unit determination
|
|
The following sequence would be wrongly optimized into a
i_get_tuple_element2 instruction, reading an element from the
wrong tuple:
{get_tuple_element,{x,0},1,{x,0}}.
{get_tuple_element,{x,0},2,{x,1}}.
|
|
The compiler would treat the "Unit" of bs_init instructions as
the unit of the result instead of the required unit of the input,
causing is_binary checks to be wrongly optimized away.
|
|
* bjorn/compiler/fix-beam_ssa_dead-patch/OTP-15845:
Fix unsafe optimizations where guard tests could be removed
|
|
'bjorng_ghub/bjorn/compiler/fix-beam_ssa_dead-crash/ERL-956/OTP-15848' into maint-22
* bjorng_ghub/bjorn/compiler/fix-beam_ssa_dead-crash/ERL-956/OTP-15848:
Eliminate crash in the beam_ssa_dead compiler pass
|
|
into maint-22
* bjorn/compiler/fix-unloadable-code-patch/ERL-955/OTP-15846:
Fix loading of Core Erlang code for extracting a map element
|
|
* bjorn/compiler/fix-beam_except/ERL-954/OTP-15839:
Fix compiler crash in beam_except
|
|
* john/compiler/list_append_type/OTP-15841:
compiler: Fix broken type for erlang:'++'/2
|
|
* bjorn/compiler/fix-receive-patch/ERL-950/OTP-15832:
Eliminate compiler crash when compiling complex receive statements
|
|
bjorng/bjorn/compiler/fix-beam_ssa_dead-crash/ERL-956/OTP-15848
Eliminate crash in the beam_ssa_dead compiler pass
|
|
|
|
A repeated test could be optimized away. Example:
bar(A) ->
if is_bitstring(A) ->
if is_binary(A) ->
binary;
true ->
bitstring
end;
true ->
other
end.
In the example, the `is_binary/1` test would be optimized away,
basically turning the example into:
bar(A) ->
if is_bitstring(A) ->
bitstring;
true ->
other
end.
Thanks user Marcus Kruse in the Elixir forum for noticing this bug.
|
|
The compiler could crash in the beam_ssa_dead pass while compiling
complex nested `case` expressions. See the added test case for an
example and explanation.
https://bugs.erlang.org/browse/ERL-956
|
|
into maint
* bjorn/compiler/fix-unloadable-code-patch/ERL-955/OTP-15846:
Fix loading of Core Erlang code for extracting a map element
|
|
* bjorn/compiler/fix-beam_ssa_dead-patch/OTP-15845:
Fix unsafe optimizations where guard tests could be removed
|
|
* bjorn/compiler/fix-beam_except/ERL-954/OTP-15839:
Fix compiler crash in beam_except
|
|
The compiler would crash in `beam_except` while compiling this
function:
bar(Req) ->
ok = case Req of
"POST" -> {error, <<"BAD METHOD ", Req/binary>>, Req};
_ -> ok
end.
https://bugs.erlang.org/browse/ERL-954
|
|
|
|
The following Core Erlang code could not be loaded:
'f'/1 = fun (_1) ->
case <_1> of
<~{'foo':='foo'}~> when 'true' ->
_1
end
Loading would fail with the following message:
beam/beam_load.c(2314): Error loading function example:f/1: op i_get_map_element_hash p x a u x:
no specific operation found
https://bugs.erlang.org/browse/ERL-955
|
|
A repeated test could be optimized away. Example:
bar(A) ->
if is_bitstring(A) ->
if is_binary(A) ->
binary;
true ->
bitstring
end;
true ->
other
end.
In the example, the `is_binary/1` test would be optimized away,
basically turning the example into:
bar(A) ->
if is_bitstring(A) ->
bitstring;
true ->
other
end.
Thanks user Marcus Kruse in the Elixir forum for noticing this bug.
|
|
* bjorn/compiler/fix-receive-patch/ERL-950/OTP-15832:
Eliminate compiler crash when compiling complex receive statements
|
|
* bjorn/compiler/fix-freeze/ERL-948/OTP-15828:
Fix non-terminating compilation
|
|
Certain complex receive statements would result in an internal
compiler failure. That would happen when the compiler would fail
to find the common exit block following a receive. See the added
test case for an example.
https://bugs.erlang.org/browse/ERL-950
|
|
The compiler would not terminate while compiling the following code:
foo(<<N:32>>, Tuple, NewValue) ->
_ = element(N, Tuple),
setelement(N, Tuple, NewValue).
The type analysis pass would attempt to construct a huge list when
attempting analyse the type of `Tuple` after the call to
`setelement/3`.
https://bugs.erlang.org/browse/ERL-948
|
|
Code such as the following would crash the compiler in OTP 22:
[some_atom = fun some_function/1]
The reason is that the fun would be copied (used both in the match
operation and as a value in the list), and the copy of the fun would
create two wrapper functions with the same name for calling
some_function/1. In OTP 21, the duplicate functions happened not to
cause any harm (one of the wrappers functions would be unused and
ultimately be removed by beam_clean). In OTP 22, the new beam_ssa_type
pass would be confused by the multiple definitions of the wrapper
function.
|
|
* john/compiler/fix-missing-match-reposition/ERL-923:
compiler: Propagate match context position on fail path
|
