tree 0260272bc233589d22fb18511b9f15753f58dc26
parent 6fc9251ae4f34c31351d9d902dd6c6cbc7baba1c
author buzbee <buzbee@google.com> 1379172065 -0700
committer Bill Buzbee <buzbee@google.com> 1379192214 +0000

Timely color fix

See b/10690000

For efficiency, the Quick compiler will not flush incoming register
arguments to the frame if their underlying Dalvik virtual registers
have been promoted to physical registers.  In this case, though,
there was a bug on Arm devices in that an incoming Double was promoted
to physical floating point registers, but not in a usable form.  The
entry code generation saw that both halves of the double were promoted,
but failed to check if it was in a form usable as a double.

In this particular case, it meant that subsequent uses of the incoming
argument referred to the uninitialized home location in the frame,
resulting in garbage color values.

That's the bug.  Another problem is that the incoming double should
never have been promoted to an unusable state in the first place - but
that's merely an efficiency issue and will be addressed in another CL.

Note: no good way to generate a regression test for this issue.  The
bug triggered because of an unusual sequence of events driving register
promotion that can't easily (or robustly) be triggered from Java source.

Change-Id: I7242422277193a04376461134dde71e9dec55576
(cherry picked from commit d0a03b8099347dee6e4bab3af95e14cd5a03b29c)