ternary expression behaviour differs in debug mode from profile mode or release mode #98967
Assignees
Labels
a: release
Challenges faced when attempting to productionize an app
c: regression
It was better in the past than it is now
dependency: dart
Dart team may need to help us
found in release: 2.10
Found to occur in 2.10
found in release: 2.11
Found to occur in 2.11
has reproducible steps
The issue has been confirmed reproducible and is ready to work on
r: fixed
Issue is closed as already fixed in a newer version
Comments
|
Hi @Kylin3216, thanks for reporting this. What platforms did you experience this issue with? |
danagbemava-nc
added
the
waiting for customer response
|
Platform was Android for me. |
Code sampleThis produces the same bug. So it does not depend on it beeing a ternary expression. |
|
Confirmed that this is reproducible on the current Flutter master branch. It looks like this is not a recent regression. |
|
@danagbemava-nc |
github-actions
bot
removed
the
waiting for customer response
|
@ToniHeiss |
|
It's a bug in compiling comparisons, more specifically when optimising null aware comparison to null unaware. We make this decision in the canonicalisation pass but don't take into account that this can change input representation requirements from tagged to unboxed. If such canonicalisation happens late in the compilation (after SelectRepresentation has already been run) then we will fail to insert appropriate conversions. This happens to work almost okay on 64-bit platforms because most values are Smis and 64-bit values fit into 1 register. But on 32-bit ARM this generates the code which almost always returns wrong result. Dart standalone reproimport 'package:expect/expect.dart';
class C {
int? val;
@pragma('vm:never-inline')
void testImpl(bool Function(int) compare) {
for (var i = 0; i < 2; i++) {
Expect.equals(false, compare(i));
val = i;
Expect.equals(true, compare(i));
}
final mint0 = int.parse("7fffffffffffffff", radix: 16);
final mint1 = int.parse("7fffffffffffffff", radix: 16);
if (mint0 != mint1) throw 'This is the same mint value';
Expect.equals(false, compare(mint0));
val = mint0;
Expect.equals(true, compare(mint0));
Expect.equals(true, compare(mint1),
'expected two different mints with the same value compare equal');
}
@pragma('vm:never-inline')
static void blackhole(void Function() f) {
f();
}
void test() {
return testImpl((v) {
// Note: need multiple context levels in the chain to delay
// optimizer forwarding load of [val] and subsequently
// clearing null_aware flag on the equality comparison.
// Hence the closure capturing [v] below.
final result = val != null ? val == v : false;
blackhole(() => v);
return result;
});
}
}
void main() {
C().test();
}@alexmarkov could you take a look at this? |
|
Thank you for the repro! This bug is similar to dart-lang/sdk#45384 which stopped reproducing at some point. |
|
Reproducible on I was not able to reproduce this on either videos
flutter doctor -v |
danagbemava-nc
added
a: release
danagbemava-nc
changed the title
copybara-service bot
pushed a commit
to dart-lang/sdk
that referenced
this issue
Feb 25, 2022
…presentations pass Before this fix, Canonicalize pass could change representation of inputs of EqualityCompare after the last SelectRepresentations pass. This results in unmatched representations and invalid code generated. The fix is to disallow canonicalization of EqualityCompare from null-aware to non-null-aware after the last SelectRepresentations. TEST=vm/dart/regress_flutter98967_test Fixes flutter/flutter#98967 Change-Id: I05359737fe322fbb2a0fe6025e3716ba5d04ebbf Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/234324 Reviewed-by: Slava Egorov <vegorov@google.com> Reviewed-by: Martin Kustermann <kustermann@google.com> Commit-Queue: Alexander Markov <alexmarkov@google.com>
|
The fix was rolled into Flutter in 38455c5. |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
danagbemava-nc
added
the
r: fixed
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Bug Description
the value of the '_selectedIndex != null ? _selectedIndex == index : false' is same with '_selectedIndex==index' in debug mode but different in profile or release mode.
Flutter Version
Steps to Reproduce
the expr
_selectedIndex != null ? _selectedIndex == index : falseis equal to_selectedIndex==indexthe expr
_selectedIndex != null ? _selectedIndex == index : falseis always falseCode sample
The text was updated successfully, but these errors were encountered: