Workaround for false positive -Wmaybe-uninitialized being triggered on some compilers

Workaround for false positive -Wmaybe-uninitialized being triggered on some compilers

Some toolchains (in this case referring to a g++ 4.9, or "arm-linux-
androideabi-g++ (GCC) 4.9 20140827 (prerelease)" according to my
--version, from the Android NDK r10e-rc4 and potentially with custom
patches; others may be affected as well) fail to prove that myVec in
WebRtcIsac_CorrelateInterVec is never used uninitialized. This is likely
due to the compiler thinking the assignment in line 468 might not
happen. Changing the loop condition in line 466 to rowCntr <
SOME_CONSTANT also helps, suggesting that the compiler can't infer that
there are only 2 values interVecDim can have at that point, and neither
of them are 0. Of course, this is not an acceptable fix, as it changes
behaviour.

This seems to be a compiler bug, or at least an issue with its
heuristics. However, we can't really change toolchains at the moment,
and ultimately this change improves support for certain older compilers.

BUG=

Committed: https://crrev.com/5460f9b81dc9bd232fa856347729f120159ae168
Cr-Commit-Position: refs/heads/master@{#10337}

[msniegocki, 2015-10-19 14:44:44]

Description was changed from

==========
Workaround for false positive -Wmaybe-uninitialized being triggered on some
compilers

Some toolchains (in this case referring to a g++ 4.9, or "arm-linux-
androideabi-g++ (GCC) 4.9 20140827 (prerelease)" according to my
--version, from the Android NDK r10e-rc4 and potentially with custom
patches; others may be affected as well) fail to prove that myVec in
WebRtcIsac_CorrelateInterVec is never used uninitialized. This is likely
due to the compiler thinking the assignment in line 468 might not
happen. Changing the loop condition in line 466 to rowCntr <
SOME_CONSTANT also helps, suggesting that the compiler can't infer that
there are only 2 values interVecDim can have at that point, and neither
of them are 0. Of course, this is not an acceptable fix, as it changes
behaviour.

This seems to be a compiler bug, or at least an issue with its
heuristics. However, we can't really change toolchains at the moment,
and ultimately this change improves support for certain older compilers.

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

to

==========
Workaround for false positive -Wmaybe-uninitialized being triggered on some
compilers

Some toolchains (in this case referring to a g++ 4.9, or "arm-linux-
androideabi-g++ (GCC) 4.9 20140827 (prerelease)" according to my
--version, from the Android NDK r10e-rc4 and potentially with custom
patches; others may be affected as well) fail to prove that myVec in
WebRtcIsac_CorrelateInterVec is never used uninitialized. This is likely
due to the compiler thinking the assignment in line 468 might not
happen. Changing the loop condition in line 466 to rowCntr <
SOME_CONSTANT also helps, suggesting that the compiler can't infer that
there are only 2 values interVecDim can have at that point, and neither
of them are 0. Of course, this is not an acceptable fix, as it changes
behaviour.

This seems to be a compiler bug, or at least an issue with its
heuristics. However, we can't really change toolchains at the moment,
and ultimately this change improves support for certain older compilers.

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

[msniegocki, 2015-10-19 14:44:44]

msniegocki@opera.com changed reviewers:
+ henrik.lundin@webrtc.org, jan.skoglund@webrtc.org, kwiberg@webrtc.org,
minyue@webrtc.org, tina.legrand@webrtc.org, turaj@webrtc.org

[turaj, 2015-10-19 16:05:38]

lgtm

[kwiberg-webrtc, 2015-10-20 09:41:46]

lgtm

[minyue-webrtc, 2015-10-20 10:34:51]

lgtm

[hlundin-webrtc, 2015-10-20 10:45:20]

lgtm

[hlundin-webrtc, 2015-10-20 11:07:22]

On 2015/10/20 10:45:20, hlundin-webrtc wrote:
> lgtm

Thanks for your contribution! I'm going to commit this now based on Opera having
previously signed a corporate Contributor License Agreement, and already being
listed in WebRTC's AUTHORS file.

[hlundin-webrtc, 2015-10-20 11:07:25]

The CQ bit was checked by henrik.lundin@webrtc.org

[commit-bot: I haz the power, 2015-10-20 11:07:30]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1406423004/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1406423004/1

[commit-bot: I haz the power, 2015-10-20 12:45:06]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-10-20 12:45:16]

Patchset 1 (id:??) landed as
https://crrev.com/5460f9b81dc9bd232fa856347729f120159ae168
Cr-Commit-Position: refs/heads/master@{#10337}