[interpreter] Fix U16 macro in test-bytecode-generator.cc.

[interpreter] Fix U16 macro in test-bytecode-generator.cc.

Avoid double incrementing of the variable in U16 macro when the variable is passed with postincrement operator.

BUG=

[akos.palfi.imgtec, 2015-11-04 10:59:13]

Description was changed from

==========
[interpreter] Fix U16 macro in test-bytecode-generator.cc.

Avoid double increment of the variable in U16 macro when the variable is passed
with postincrement operator.

BUG=
==========

to

==========
[interpreter] Fix U16 macro in test-bytecode-generator.cc.

Avoid double incrementing of the variable in U16 macro when the variable is
passed with postincrement operator.

BUG=
==========

[akos.palfi.imgtec, 2015-11-04 11:02:05]

akos.palfi@imgtec.com changed reviewers:
+ balazs.kilvady@imgtec.com, paul.lind@imgtec.com, rmcilroy@chromium.org

[akos.palfi.imgtec, 2015-11-04 11:02:05]

Hi Ross,

This patch tries to avoid to double substitution of the variable in the U16
macro. In some tests the U16 macro is called with post-increment operator:
U16(wide_idx++). This is problematic because in this case the wide_idx variable
gets incremented twice when the U16 macro is expanded
(static_cast<uint8_t>((wide_idx++) & 0xff), static_cast<uint8_t>(((wide_idx++)
>> kBitsPerByte) & 0xff)) and the macro will extract the first byte of wide_idx
and the second byte of wide_idx + 1, since it gets incremented after accessing
the first byte.
This problem appears only on big-endian due to the fortunate value of wide_idx
in some tests. For example in 'HeapNumberConstants' it's value is 256 when it's
passed to the U16 macro. So it will extract the first byte of 256 and the second
byte of 257.
On little-endian archs, 256 is 00 01 and 257 is 01 01 and the result will be 00
01, which is 256.
On big-endian archs, 256 is 01 00 and 257 is 01 01 and the result will be 01 01,
which is 257 and wrong.
I don't treat this patch as 'production-ready', I just wanted to demonstrate the
bug. However, I wasn't able to create a better patch without major changes in
the tests.
Could you help us with creating a cleaner patch?

[rmcilroy, 2015-11-04 18:33:18]

Ahh, sorry about that. It turns out we can avoid having the post-increments in
the test entirely. I've done this in https://codereview.chromium.org/1423593005/
does this solve your problem?

[akos.palfi.imgtec, 2015-11-04 19:08:15]

Thanks Ross, I'm closing this.

Fixed by https://codereview.chromium.org/1431803004/