avoid 'may be used uninitialized' warnings in work_queue.cc

avoid 'may be used uninitialized' warnings in work_queue.cc

GCC gives 'may be used uninitialized' warnings for enqueue_order
and other_enqueue_order, so let's ensure that they're initialized.

Committed: https://crrev.com/d5256aa193b1777896a458de2c547bea003c977a
Cr-Commit-Position: refs/heads/master@{#375558}

[Mostyn Bramley-Moore, 2016-02-15 19:47:11]

Description was changed from

==========
avoid 'may be used uninitialized' warnings in work_queue.cc
==========

to

==========
avoid 'may be used uninitialized' warnings in work_queue.cc

GCC gives 'may be used uninitialized' warnings for enqueue_order
and other_enqueue_order, so let's ensure that they're initialized.
==========

[Mostyn Bramley-Moore, 2016-02-15 19:47:41]

mostynb@opera.com changed reviewers:
+ skyostil@chromium.org

[Mostyn Bramley-Moore, 2016-02-15 19:47:42]

@Sami: please take a look at this tiny GCC fixup.

[Mostyn Bramley-Moore, 2016-02-15 19:47:50]

The CQ bit was checked by mostynb@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-02-15 19:47:58]

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

[commit-bot: I haz the power, 2016-02-15 20:57:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-15 20:57:54]

Dry run: This issue passed the CQ dry run.

[Sami, 2016-02-16 12:06:36]

Thanks, lgtm.

I wonder why GCC can't figure out that these variables will always be
initialized. Might be some pointer aliasing issue.

[Mostyn Bramley-Moore, 2016-02-16 13:32:45]

The CQ bit was checked by mostynb@opera.com

[commit-bot: I haz the power, 2016-02-16 13:33:35]

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

[commit-bot: I haz the power, 2016-02-16 13:38:14]

Description was changed from

==========
avoid 'may be used uninitialized' warnings in work_queue.cc

GCC gives 'may be used uninitialized' warnings for enqueue_order
and other_enqueue_order, so let's ensure that they're initialized.
==========

to

==========
avoid 'may be used uninitialized' warnings in work_queue.cc

GCC gives 'may be used uninitialized' warnings for enqueue_order
and other_enqueue_order, so let's ensure that they're initialized.
==========

[commit-bot: I haz the power, 2016-02-16 13:38:14]

Committed patchset #1 (id:1)

[Mostyn Bramley-Moore, 2016-02-16 13:39:08]

> I wonder why GCC can't figure out that these variables will always be
> initialized. Might be some pointer aliasing issue.

GetFrontTaskEnqueueOrder() can return without modifying the pointed-to argument-
I'm not sure if clang is clever enough to figure out that this case does not
occur (unlikely, I suspect), or if clang just assumes that these variables are
initialized inside GetFrontTaskEnqueueOrder().

[commit-bot: I haz the power, 2016-02-16 22:52:26]

Description was changed from

==========
avoid 'may be used uninitialized' warnings in work_queue.cc

GCC gives 'may be used uninitialized' warnings for enqueue_order
and other_enqueue_order, so let's ensure that they're initialized.
==========

to

==========
avoid 'may be used uninitialized' warnings in work_queue.cc

GCC gives 'may be used uninitialized' warnings for enqueue_order
and other_enqueue_order, so let's ensure that they're initialized.

Committed: https://crrev.com/d5256aa193b1777896a458de2c547bea003c977a
Cr-Commit-Position: refs/heads/master@{#375558}
==========

[commit-bot: I haz the power, 2016-02-16 22:52:26]

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