Make dynamic_annotations build with -Wconstant-conversion from newer clangs.

Make libwebp build with -Wconstant-conversion from newer clangs.

After http://llvm.org/viewvc/llvm-project?rev=259271&view=rev, clang points
out that _mm_set1_epi16(33050) causes an overflow in the short argument to
_mm_set1_epi16().  Since there's no version that takes an unsigned short,
add an explicit cast to tell the compiler that this is intentional.

No behavior change.

BUG=none
R=urvang@chromium.org

Committed: https://crrev.com/3ecb59fbcff8fa062d066c41d4b27ed6ece05403
Cr-Commit-Position: refs/heads/master@{#373004}

[Nico, 2016-02-02 15:00:20]

thakis@chromium.org changed reviewers:
+ jzern@chromium.org

[Nico, 2016-02-02 15:00:20]

Does this need to be upstreamed to somewhere? If so, to where?

[urvang, 2016-02-02 19:25:22]

urvang@chromium.org changed reviewers:
+ urvang@chromium.org

[urvang, 2016-02-02 19:25:22]

lgtm

We typically change it upstream first and cherry-pick here, but I'll make an
exception here as it's urgent.

[Nico, 2016-02-02 19:25:52]

The CQ bit was checked by thakis@chromium.org

[commit-bot: I haz the power, 2016-02-02 19:27:12]

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

[Nico, 2016-02-02 19:37:22]

Description was changed from

==========
Make libwebp build with -Wconstant-conversion from newer clangs.

After http://llvm.org/viewvc/llvm-project?rev=259271&view=rev, clang points
out that _mm_set1_epi16(33050) causes an overflow in the short argument to
_mm_set1_epi16().  Since there's no version that takes an unsigned short,
add an explicit cast to tell the compiler that this is intentional.

No behavior change.

BUG=none
==========

to

==========
Make libwebp build with -Wconstant-conversion from newer clangs.

After http://llvm.org/viewvc/llvm-project?rev=259271&view=rev, clang points
out that _mm_set1_epi16(33050) causes an overflow in the short argument to
_mm_set1_epi16().  Since there's no version that takes an unsigned short,
add an explicit cast to tell the compiler that this is intentional.

No behavior change.

BUG=none
R=urvang@chromium.org
==========

[Nico, 2016-02-02 19:37:23]

Committed patchset #1 (id:1) to pending queue manually as
70f6f036e286070139da7600fe6b1d1d3c4de7b5 (presubmit successful).

[commit-bot: I haz the power, 2016-02-02 19:38:27]

Description was changed from

==========
Make libwebp build with -Wconstant-conversion from newer clangs.

After http://llvm.org/viewvc/llvm-project?rev=259271&view=rev, clang points
out that _mm_set1_epi16(33050) causes an overflow in the short argument to
_mm_set1_epi16().  Since there's no version that takes an unsigned short,
add an explicit cast to tell the compiler that this is intentional.

No behavior change.

BUG=none
R=urvang@chromium.org
==========

to

==========
Make libwebp build with -Wconstant-conversion from newer clangs.

After http://llvm.org/viewvc/llvm-project?rev=259271&view=rev, clang points
out that _mm_set1_epi16(33050) causes an overflow in the short argument to
_mm_set1_epi16().  Since there's no version that takes an unsigned short,
add an explicit cast to tell the compiler that this is intentional.

No behavior change.

BUG=none
R=urvang@chromium.org

Committed: https://crrev.com/3ecb59fbcff8fa062d066c41d4b27ed6ece05403
Cr-Commit-Position: refs/heads/master@{#373004}
==========

[commit-bot: I haz the power, 2016-02-02 19:38:28]

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

[jzern, 2016-02-02 21:13:52]

On 2016/02/02 15:00:20, Nico wrote:
> Does this need to be upstreamed to somewhere? If so, to where?

libwebp's canonical repo is https://chromium.googlesource.com/webm/libwebp. I
can upstream this later, the builders are being cycled to roll back the clang
version there; 3.7.1 causes some issues with libvpx: one in that code (vp9
encoder+TSAN) and one with a crash when using coverage+asan.

[Nico, 2016-02-02 21:16:15]

On 2016/02/02 21:13:52, jzern wrote:
> On 2016/02/02 15:00:20, Nico wrote:
> > Does this need to be upstreamed to somewhere? If so, to where?
> 
> libwebp's canonical repo is https://chromium.googlesource.com/webm/libwebp. I
> can upstream this later, the builders are being cycled to roll back the clang
> version there; 3.7.1 causes some issues with libvpx: one in that code (vp9
> encoder+TSAN) and one with a crash when using coverage+asan.

In Chromium, we don't use LLVM's releases, we have our own clang binary that
tracks LLVM trunk (which is currently at 3.9.0). Maybe you can use that binary
too?

[jzern, 2016-02-02 21:22:36]

On 2016/02/02 21:16:15, Nico wrote:
> On 2016/02/02 21:13:52, jzern wrote:
> > On 2016/02/02 15:00:20, Nico wrote:
> > > Does this need to be upstreamed to somewhere? If so, to where?
> > 
> > libwebp's canonical repo is https://chromium.googlesource.com/webm/libwebp.
I
> > can upstream this later, the builders are being cycled to roll back the
clang
> > version there; 3.7.1 causes some issues with libvpx: one in that code (vp9
> > encoder+TSAN) and one with a crash when using coverage+asan.
> 
> In Chromium, we don't use LLVM's releases, we have our own clang binary that
> tracks LLVM trunk (which is currently at 3.9.0). Maybe you can use that binary
> too?

That could work, I'm not using anything exotic (asan/tsan/ubsan, x86-64 & x86).
These run on GCE on an older debian (wheezy; we could move to jessie easily
enough), so lib compatibility might be an issue with those binaries.

[Nico, 2016-02-02 21:24:14]

On 2016/02/02 21:22:36, jzern wrote:
> On 2016/02/02 21:16:15, Nico wrote:
> > On 2016/02/02 21:13:52, jzern wrote:
> > > On 2016/02/02 15:00:20, Nico wrote:
> > > > Does this need to be upstreamed to somewhere? If so, to where?
> > > 
> > > libwebp's canonical repo is
https://chromium.googlesource.com/webm/libwebp.
> I
> > > can upstream this later, the builders are being cycled to roll back the
> clang
> > > version there; 3.7.1 causes some issues with libvpx: one in that code (vp9
> > > encoder+TSAN) and one with a crash when using coverage+asan.
> > 
> > In Chromium, we don't use LLVM's releases, we have our own clang binary that
> > tracks LLVM trunk (which is currently at 3.9.0). Maybe you can use that
binary
> > too?
> 
> That could work, I'm not using anything exotic (asan/tsan/ubsan, x86-64 &
x86).
> These run on GCE on an older debian (wheezy; we could move to jessie easily
> enough), so lib compatibility might be an issue with those binaries.

Chromium's clangs run on Precise, which might be old enough to work? You can
check out pdfium's and v8's DEPS files on how to pull in chromium's clang.

[jzern, 2016-02-02 22:38:43]

On 2016/02/02 21:24:14, Nico wrote:
> On 2016/02/02 21:22:36, jzern wrote:
> > On 2016/02/02 21:16:15, Nico wrote:
> > > On 2016/02/02 21:13:52, jzern wrote:
> > > > On 2016/02/02 15:00:20, Nico wrote:
> > > > > Does this need to be upstreamed to somewhere? If so, to where?
> > > > 
> > > > libwebp's canonical repo is
> https://chromium.googlesource.com/webm/libwebp.
> > I
> > > > can upstream this later, the builders are being cycled to roll back the
> > clang
> > > > version there; 3.7.1 causes some issues with libvpx: one in that code
(vp9
> > > > encoder+TSAN) and one with a crash when using coverage+asan.
> > > 
> > > In Chromium, we don't use LLVM's releases, we have our own clang binary
that
> > > tracks LLVM trunk (which is currently at 3.9.0). Maybe you can use that
> binary
> > > too?
> > 
> > That could work, I'm not using anything exotic (asan/tsan/ubsan, x86-64 &
> x86).
> > These run on GCE on an older debian (wheezy; we could move to jessie easily
> > enough), so lib compatibility might be an issue with those binaries.
> 
> Chromium's clangs run on Precise, which might be old enough to work? You can
> check out pdfium's and v8's DEPS files on how to pull in chromium's clang.

Close, but no: libc6 2.13 vs. 2.15