27 lines
1.4 KiB
Plaintext
27 lines
1.4 KiB
Plaintext
Exercise a method containing a `try' statement with several
|
|
instructions with a `finally' clause but without any `catch' block,
|
|
enclosed in a loop.
|
|
|
|
When dx processes an integer division (or modulo) enclosing a `try'
|
|
block and whose result is assigned to a local value, it is smart
|
|
enough not to emit a `div-int' (or `rem-int') instruction when the
|
|
divisor is non-null, as it wouldn't be used. However, dx is not
|
|
that clever regarding exception handling: if the divisor is known to
|
|
be non-null at compile-time (as is the case in this test), it will
|
|
still emit a block with the exception catching and rethrowing
|
|
mechanism, even if it is not used.
|
|
|
|
This used to be a problem for a `try' block followed by a `finally'
|
|
clause but with no `catch' block: in that case, the generated Dex code
|
|
item would list zero catch block for this method (see
|
|
art::CodeItem::tries_size_) and the optimizing compiler would have no
|
|
clue that it contains a `try' statement, which it cannot optimize
|
|
(yet). With no hint that this method might contain one (or several)
|
|
special block(s) related to `catch'-less `try' statement(s), the
|
|
optimizing compiler considered this (these) as dead block(s) and
|
|
improperly tried to remove its (their) instructions, sometimes
|
|
removing instructions used by others instructions, thus triggering
|
|
assertions. The optimizing compiler was thus adjusted to remove these
|
|
instructions in a proper fashion, by removing them as users first, and
|
|
then by suppressing them for good.
|