Update to libjpeg_turbo 1.4.90

Update to libjpeg_turbo 1.4.90

BUG=608347, 398235, 591927

[msarett, 2016-05-02 16:41:00]

Description was changed from

==========
Update to 1.4.90

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

to

==========
Update to 1.4.90

BUG=608347
==========

[msarett, 2016-05-02 16:46:42]

Description was changed from

==========
Update to 1.4.90

BUG=608347
==========

to

==========
Update to libjpeg-turbo 1.4.90

BUG=608347
==========

[msarett, 2016-05-02 16:49:24]

Description was changed from

==========
Update to libjpeg-turbo 1.4.90

BUG=608347
==========

to

==========
Update to libjpeg_turbo 1.4.90

BUG=608347
==========

[msarett, 2016-05-02 17:02:10]

Patchset #1 (id:1) has been deleted

[msarett, 2016-05-02 17:03:03]

msarett@google.com changed reviewers:
+ noel@chromium.org, scroggo@chromium.org, thakis@chromium.org

[msarett, 2016-05-02 17:03:07]

This needs to land simultaneously with an update to the BUILD.gn file.  I'm not
sure how to do that.
https://codereview.chromium.org/1935113002/

I also think we are most likely blocked by a clang compatibility issue with the
ARM32 assembly.  Though, if the fix is slow to get into upstream, we have the
option to add it as a Chromium specific modification.
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/75

Finally, in a follow-up, I think I'll need to add back in Chromium's private
modifiers on the assembly functions.  This is a pain, anybody remember why we
need this?
https://codereview.chromium.org/6246098

[msarett, 2016-05-02 23:22:44]

On 2016/05/02 17:03:07, msarett wrote:
> This needs to land simultaneously with an update to the BUILD.gn file.  I'm
not
> sure how to do that.
> https://codereview.chromium.org/1935113002/
> 
> I also think we are most likely blocked by a clang compatibility issue with
the
> ARM32 assembly.  Though, if the fix is slow to get into upstream, we have the
> option to add it as a Chromium specific modification.
> https://github.com/libjpeg-turbo/libjpeg-turbo/pull/75
> 

This has been submitted to upstream master, and I've cherry picked it here.
So we are no longer blocked.

> Finally, in a follow-up, I think I'll need to add back in Chromium's private
> modifiers on the assembly functions.  This is a pain, anybody remember why we
> need this?
> https://codereview.chromium.org/6246098

[Nico, 2016-05-02 23:26:28]

Landing-wise, I think you land this, and then you update .gn files in the same
CL as updating DEPS to pull in a new version of chromium/deps/libjpeg_turbo.git

[Nico, 2016-05-02 23:35:39]

re that upstream patch: I think where we landed with the clang UAL discussion
was that if a) something has an UAL form and b) that form actually works, then
it makes sense to update projects to use that. In this case, it looks like
there's no form that works across compilers, so for that it doesn't seem
unreasonable to teach clang's assembler an old intrinsic. The test I use is "is
there a way to write what I want to write that works in all modern compilers?"
If so, then we should use that. Else, we should work on creating a world where
it is possible to write code that's portable across compilers...somehow. In most
cases, the easiest route there will be to teach clang about some instruction it
doesn't know about yet.

[Nico, 2016-05-02 23:38:08]

do we have to add doc/ and testimages/? How large are these folders?

Generally this looks fine (thanks much for doing this!). If noel and scroggo
don't comment, i'll lg.

[renato.golin_linaro.org, 2016-05-03 09:23:00]

This patch set is not a "Clang compatibility fix", but a
"libjpeg_turbo upgrade". Makes no sense to have all those files marked
as a "Clang fix".

Also, as per our last email, this has nothing to so with pre-UAL syntax.

On 3 May 2016 at 00:38,  <thakis@chromium.org> wrote:
> do we have to add doc/ and testimages/? How large are these folders?
>
> Generally this looks fine (thanks much for doing this!). If noel and scroggo
> don't comment, i'll lg.
>
> https://codereview.chromium.org/1939823002/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[msarett, 2016-05-03 13:20:06]

"Landing-wise, I think you land this, and then you update .gn files in the same
CL as updating DEPS to pull in a new version of chromium/deps/libjpeg_turbo.git"

Ahh yes of course!

"re that upstream patch: I think where we landed with the clang UAL discussion
was that if a) something has an UAL form and b) that form actually works, then
it makes sense to update projects to use that. In this case, it looks like
there's no form that works across compilers, so for that it doesn't seem
unreasonable to teach clang's assembler an old intrinsic. The test I use is "is
there a way to write what I want to write that works in all modern compilers?"
If so, then we should use that. Else, we should work on creating a world where
it is possible to write code that's portable across compilers...somehow. In most
cases, the easiest route there will be to teach clang about some instruction it
doesn't know about yet."

Very interesting!  If I want to suggest that clang support
"streqb", do you know who is the right person to reach out
to?  It'd be great if libjpeg-turbo didn't need the ifdef.

Still I think it's nice for the library to be compatible
with older versions of clang.  I don't think this needs to
block the library update.

"do we have to add doc/ and testimages/? How large are
these folders?"

doc/ is 796 KB and testimages/ is 340 KB.  We can certainly
delete these.  It's generally my preference to mess with
the upstream library as little as possible (to make future
updates easier), but this is a pretty simple change.

Let me know if you think it's worth deleting those
directories at those sizes.

"This patch set is not a "Clang compatibility fix", but a
"libjpeg_turbo upgrade". Makes no sense to have all those files marked
as a "Clang fix".

Also, as per our last email, this has nothing to so with pre-UAL syntax."

Apologies for being unclear.  The Patch Set is so large
that I think Patch Set diffs aren't working.

A *difference* between Patch Set 1 and Patch Set 2 is that
I've cherry-picked an upstream commit so that clang can
compile the Arm32 assembly.
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/5e576386b57663bbe9d934e...

Agreed that this CL is better marked as a "libjpeg-turbo
upgrade".

[renato.golin_linaro.org, 2016-05-03 13:24:02]

Clang doesn't need to support streqb, GAS already understand strbeq,
you just need to add ".syntax unified" to the begining of the source
file.

On 3 May 2016 at 14:20,  <msarett@google.com> wrote:
> "Landing-wise, I think you land this, and then you update .gn files in the
> same
> CL as updating DEPS to pull in a new version of
> chromium/deps/libjpeg_turbo.git"
>
> Ahh yes of course!
>
> "re that upstream patch: I think where we landed with the clang UAL
> discussion
> was that if a) something has an UAL form and b) that form actually works,
> then
> it makes sense to update projects to use that. In this case, it looks like
> there's no form that works across compilers, so for that it doesn't seem
> unreasonable to teach clang's assembler an old intrinsic. The test I use is
> "is
> there a way to write what I want to write that works in all modern
> compilers?"
> If so, then we should use that. Else, we should work on creating a world
> where
> it is possible to write code that's portable across compilers...somehow. In
> most
> cases, the easiest route there will be to teach clang about some instruction
> it
> doesn't know about yet."
>
> Very interesting! If I want to suggest that clang support
> "streqb", do you know who is the right person to reach out
> to? It'd be great if libjpeg-turbo didn't need the ifdef.
>
> Still I think it's nice for the library to be compatible
> with older versions of clang. I don't think this needs to
> block the library update.
>
> "do we have to add doc/ and testimages/? How large are
> these folders?"
>
> doc/ is 796 KB and testimages/ is 340 KB. We can certainly
> delete these. It's generally my preference to mess with
> the upstream library as little as possible (to make future
> updates easier), but this is a pretty simple change.
>
> Let me know if you think it's worth deleting those
> directories at those sizes.
>
> "This patch set is not a "Clang compatibility fix", but a
> "libjpeg_turbo upgrade". Makes no sense to have all those files marked
> as a "Clang fix".
>
> Also, as per our last email, this has nothing to so with pre-UAL syntax."
>
> Apologies for being unclear. The Patch Set is so large
> that I think Patch Set diffs aren't working.
>
> A *difference* between Patch Set 1 and Patch Set 2 is that
> I've cherry-picked an upstream commit so that clang can
> compile the Arm32 assembly.
>
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/5e576386b57663bbe9d934e...
>
> Agreed that this CL is better marked as a "libjpeg-turbo
> upgrade".
>
> https://codereview.chromium.org/1939823002/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Noel Gordon, 2016-05-03 13:26:27]

On 2016/05/03 13:20:06, msarett wrote:

> doc/ is 796 KB and testimages/ is 340 KB.  We can certainly
> delete these.

Looks like release/ could go and a few others too.  Let's strip it down to the
essentials, please.

[Nico, 2016-05-03 13:32:40]

On Tue, May 3, 2016 at 9:24 AM, Renato Golin <renato.golin@linaro.org>
wrote:

> Clang doesn't need to support streqb, GAS already understand strbeq,
> you just need to add ".syntax unified" to the begining of the source
> file.
>

Ah, of course, thanks!

msarett, that sounds like a better upstream fix, yes?

(Renato: I think it would be very useful to have some "how to make your
existing arm assembly UAL compatible" guide somewhere on llvm.org)


>
> On 3 May 2016 at 14:20,  <msarett@google.com> wrote:
> > "Landing-wise, I think you land this, and then you update .gn files in
> the
> > same
> > CL as updating DEPS to pull in a new version of
> > chromium/deps/libjpeg_turbo.git"
> >
> > Ahh yes of course!
> >
> > "re that upstream patch: I think where we landed with the clang UAL
> > discussion
> > was that if a) something has an UAL form and b) that form actually works,
> > then
> > it makes sense to update projects to use that. In this case, it looks
> like
> > there's no form that works across compilers, so for that it doesn't seem
> > unreasonable to teach clang's assembler an old intrinsic. The test I use
> is
> > "is
> > there a way to write what I want to write that works in all modern
> > compilers?"
> > If so, then we should use that. Else, we should work on creating a world
> > where
> > it is possible to write code that's portable across compilers...somehow.
> In
> > most
> > cases, the easiest route there will be to teach clang about some
> instruction
> > it
> > doesn't know about yet."
> >
> > Very interesting! If I want to suggest that clang support
> > "streqb", do you know who is the right person to reach out
> > to? It'd be great if libjpeg-turbo didn't need the ifdef.
> >
> > Still I think it's nice for the library to be compatible
> > with older versions of clang. I don't think this needs to
> > block the library update.
> >
> > "do we have to add doc/ and testimages/? How large are
> > these folders?"
> >
> > doc/ is 796 KB and testimages/ is 340 KB. We can certainly
> > delete these. It's generally my preference to mess with
> > the upstream library as little as possible (to make future
> > updates easier), but this is a pretty simple change.
> >
> > Let me know if you think it's worth deleting those
> > directories at those sizes.
> >
> > "This patch set is not a "Clang compatibility fix", but a
> > "libjpeg_turbo upgrade". Makes no sense to have all those files marked
> > as a "Clang fix".
> >
> > Also, as per our last email, this has nothing to so with pre-UAL syntax."
> >
> > Apologies for being unclear. The Patch Set is so large
> > that I think Patch Set diffs aren't working.
> >
> > A *difference* between Patch Set 1 and Patch Set 2 is that
> > I've cherry-picked an upstream commit so that clang can
> > compile the Arm32 assembly.
> >
>
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/5e576386b57663bbe9d934e...
> >
> > Agreed that this CL is better marked as a "libjpeg-turbo
> > upgrade".
> >
> > https://codereview.chromium.org/1939823002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[msarett, 2016-05-03 13:40:50]

> > Clang doesn't need to support streqb, GAS already understand strbeq,
> > you just need to add ".syntax unified" to the begining of the source
> > file.

> Ah, of course, thanks!
> 
> msarett, that sounds like a better upstream fix, yes?

> (Renato: I think it would be very useful to have some "how to make your
> existing arm assembly UAL compatible" guide somewhere on llvm.org)"

Yes absolutely!  Thanks for this tip.  I'll test this out
and suggest it to upstream.

> > doc/ is 796 KB and testimages/ is 340 KB.  We can certainly
> > delete these.

> Looks like release/ could go and a few others too.  Let's > strip it down to
the
> essentials, please.

SGTM!  I've deleted unused directories: cmakescripts, doc,
java, md5, release, sharedlib, testimages, and win

[msarett, 2016-05-03 14:03:28]

> Clang doesn't need to support streqb, GAS already understand strbeq,
> you just need to add ".syntax unified" to the begining of the source
> file.

This fix isn't working for me...  I've removed the previous
fix and tried adding ".syntax unified" to the start of the
assembly file, but I'm still hitting errors on streqb.

<instantiation>:7:5: error: invalid instruction
    streqb r0, [r10, #1]!

I'm not extremely familiar with assembler intricacies, so
please let me know if I'm doing/interpreting something
wrong.

My understanding is that GAS is used with GCC, but clang
has its own integrated assembler.  Maybe clang is used with
GAS if I pass in "--no-integrated-assembler"?  I believe
this fixes the problem.

However, some clients of libjpeg-turbo (ex: Android) want
to use clang + clang's assembler, so I'm not sure we can
always rely on GAS?

[renato.golin_linaro.org, 2016-05-03 14:22:54]

On 3 May 2016 at 15:03,  <msarett@google.com> wrote:
> This fix isn't working for me... I've removed the previous
> fix and tried adding ".syntax unified" to the start of the
> assembly file, but I'm still hitting errors on streqb.

Sorry, you missed the context:

https://llvm.org/bugs/show_bug.cgi?id=23507

You have to change all "xxxEQx" instructions to "xxxxEQ", since this
is the new unified syntax.

The fix is both to change the name AND add the ".syntax unified".

cheers,
--renato

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[msarett, 2016-05-03 14:29:39]

On 2016/05/03 14:22:54, renato.golin_linaro.org wrote:
> On 3 May 2016 at 15:03,  <mailto:msarett@google.com> wrote:
> > This fix isn't working for me... I've removed the previous
> > fix and tried adding ".syntax unified" to the start of the
> > assembly file, but I'm still hitting errors on streqb.
> 
> Sorry, you missed the context:
> 
> https://llvm.org/bugs/show_bug.cgi?id=23507
> 
> You have to change all "xxxEQx" instructions to "xxxxEQ", since this
> is the new unified syntax.
> 
> The fix is both to change the name AND add the ".syntax unified".
> 
> cheers,
> --renato
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Chromium-reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.
> 

Ah thanks :)

[msarett, 2016-05-03 15:55:19]

FYI, I'm getting a little bit of push back from upstream on
the "better" fix.
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/76

Looks like I need to do a little bit of digging into GCC.

If this drags out, I think we are fine to land this update as
is, but I'm optimistic we can resolve it.

[renato.golin_linaro.org, 2016-05-03 17:57:54]

Updated the github review. If that file compiles well (ie. no other
syntax issues), it will work in the exact same way.

On 3 May 2016 at 16:55,  <msarett@google.com> wrote:
> FYI, I'm getting a little bit of push back from upstream on
> the "better" fix.
> https://github.com/libjpeg-turbo/libjpeg-turbo/pull/76
>
> Looks like I need to do a little bit of digging into GCC.
>
> If this drags out, I think we are fine to land this update as
> is, but I'm optimistic we can resolve it.
>
> https://codereview.chromium.org/1939823002/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[msarett, 2016-05-03 18:53:23]

On 2016/05/03 17:57:54, renato.golin_linaro.org wrote:
> Updated the github review. If that file compiles well (ie. no other
> syntax issues), it will work in the exact same way.
> 
> On 3 May 2016 at 16:55,  <mailto:msarett@google.com> wrote:
> > FYI, I'm getting a little bit of push back from upstream on
> > the "better" fix.
> > https://github.com/libjpeg-turbo/libjpeg-turbo/pull/76
> >
> > Looks like I need to do a little bit of digging into GCC.
> >
> > If this drags out, I think we are fine to land this update as
> > is, but I'm optimistic we can resolve it.
> >
> > https://codereview.chromium.org/1939823002/
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Chromium-reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.
> 

Renato, thanks a lot for weighing in on that!

I've updated this CL to include the improved fix.  I think this is ready!

[Nico, 2016-05-03 18:57:37]

lgtm, let's see what the try bots think about this.

Thanks for working on this, and thanks to Khasim and Renato for the help!

[Nico, 2016-05-03 18:58:08]

(try jobs are only available when you roll the new version into chromium I
believe, not for landing this)

[renato.golin_linaro.org, 2016-05-03 19:13:52]

I don't follow the bots, but feel free to point me at them if there's
any problem.

On 3 May 2016 at 19:58,  <thakis@chromium.org> wrote:
> (try jobs are only available when you roll the new version into chromium I
> believe, not for landing this)
>
> https://codereview.chromium.org/1939823002/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[msarett, 2016-05-03 19:30:46]

I'm failing on "git cl land" (and also "git push").

 299 files changed, 70034 insertions(+), 37350 deletions(-)
Counting objects: 244, done.
Delta compression using up to 40 threads.
Compressing objects: 100% (243/243), done.
Writing objects: 100% (244/244), 517.46 KiB | 0 bytes/s, done.
Total 244 (delta 157), reused 0 (delta 0)
remote: Resolving deltas: 100% (157/157)
remote: Processing changes: refs: 1, done    
error: failed to push some refs to
'https://chromium.googlesource.com/chromium/deps/libjpeg_turbo.git'
Failed to push. If this persists, please file a bug.

I suspect it's because I don't have the proper permissions.  Is anyone able to
land on my behalf?

[Nico, 2016-05-03 20:11:53]

I tried landing this:

thakis@thakis:~/src/chrome/src/third_party/libjpeg_turbo$ git cl patch -b land
1939823002
Switched to a new branch 'land'
Request to https://codereview.chromium.org/download/issue1939823002_50001.diff
failed: Patch set (50001) is too large.

Is it possible for you to find someone local with commit permissions?

[Noel Gordon, 2016-05-04 12:58:04]

Maybe some more we could remove?

Makefile.am
acinclude.m4
configure.ac
doxygen*
*.in
simd/*altivec*
simd/*powerpc*
simd/*mips*
turbojpeg-mapfile*

[msarett, 2016-05-04 13:09:51]

On 2016/05/04 12:58:04, noel gordon wrote:
> Maybe some more we could remove?
> 
> Makefile.am
> acinclude.m4
> configure.ac
> doxygen*
> *.in
> simd/*altivec*
> simd/*powerpc*
> simd/*mips*
> turbojpeg-mapfile*

Agreed that we could.  We could also remove pretty much every file that doesn't
start with a J.  But I don't think we want to do this.  Updating the library
will become a pain because no commits from upstream will merge cleanly - we will
essentially be maintaining a fork.

I'm not sure I see the benefit of removing the mips and altivec SIMD.  For now
it's harmless, and if we ever want to start supporting this code, the process
will be simple.  IMHO, there is real value (in terms of time/effort) to being on
a clean copy of upstream.

[Noel Gordon, 2016-05-04 13:18:07]

https://codereview.chromium.org/1939823002/diff/50001/README.chromium
File README.chromium (left):

https://codereview.chromium.org/1939823002/diff/50001/README.chromium#oldcode54
README.chromium:54: 
Looks like we've removed this group of 4 fixes.  What's the plan here?

Also, does 1.4.90 have the https://crbug.com/591927 fix?

https://codereview.chromium.org/1939823002/diff/50001/config.h
File config.h (left):

https://codereview.chromium.org/1939823002/diff/50001/config.h#oldcode14
config.h:14: /* #undef MEM_SRCDST_SUPPORTED */
You should compare this file to the new config files to check if there were
differences.  For example, I noticed the patch enables this flag, but it wasn't
needed before.  Made me wonder why we need it.

[Noel Gordon, 2016-05-04 13:28:52]

On 2016/05/04 13:09:51, msarett wrote:
> On 2016/05/04 12:58:04, noel gordon wrote:
> > Maybe some more we could remove?
> > 
> > Makefile.am
> > acinclude.m4
> > configure.ac
> > doxygen*
> > *.in
> > simd/*altivec*
> > simd/*powerpc*
> > simd/*mips*
> > turbojpeg-mapfile*
> 
> Agreed that we could.  We could also remove pretty much every file that
doesn't
> start with a J. ...
> I'm not sure I see the benefit of removing the mips and altivec SIMD.  For now
> it's harmless, and if we ever want to start supporting this code, the process
> will be simple.

Many so it's less for me to read / review :)

[Noel Gordon, 2016-05-04 13:32:35]

Ahem, _mainly_ so it's less for me to read / review :) see #30.

[msarett, 2016-05-04 15:24:12]

Thanks for your thoughts Noel!  I've addressed your comments.  Because
codereview isn't being helpful, here are the modified files:

#	modified:   README.chromium
#	modified:   jconfig.h
#	modified:   jdhuff.c
#	modified:   jdhuff.h
#	modified:   jstdhuff.c
#	modified:   simd/jsimd_arm.c

https://codereview.chromium.org/1939823002/diff/50001/README.chromium
File README.chromium (left):

https://codereview.chromium.org/1939823002/diff/50001/README.chromium#oldcode54
README.chromium:54: 
On 2016/05/04 13:18:07, noel gordon wrote:
> Looks like we've removed this group of 4 fixes.  What's the plan here?
> 

(1) private_extern flags
I intend to add this back in a follow-up before we roll DEPS.
(2) Motion jpeg
This was fixed upstream, so we have it :).
http://hg.mozilla.org/mozilla-central/rev/fac849dd7be9
(3) 6b compatibility
Per our conversation on chat, let's reapply this, but also plan to investigate
later.
(4) Fixed an issue with Arm NEON build
Thanks again for pointing this out!  I'll add it back in.  This looks like it
could potentially be a bug in upstream.  I may follow up there.

> Also, does 1.4.90 have the https://crbug.com/591927 fix?

Hmm apparently not.  I've added this in.

https://codereview.chromium.org/1939823002/diff/50001/config.h
File config.h (left):

https://codereview.chromium.org/1939823002/diff/50001/config.h#oldcode14
config.h:14: /* #undef MEM_SRCDST_SUPPORTED */
On 2016/05/04 13:18:07, noel gordon wrote:
> You should compare this file to the new config files to check if there were
> differences.  For example, I noticed the patch enables this flag, but it
wasn't
> needed before.  Made me wonder why we need it.

Hmmm, we don't need it.  My fault, I thought I checked these.  I've fixed this.

[Noel Gordon, 2016-05-04 15:53:36]

https://codereview.chromium.org/1939823002/diff/50001/README.chromium
File README.chromium (left):

https://codereview.chromium.org/1939823002/diff/50001/README.chromium#oldcode54
README.chromium:54: 
On 2016/05/04 15:24:12, msarett wrote:
> On 2016/05/04 13:18:07, noel gordon wrote:
> > Looks like we've removed this group of 4 fixes.  What's the plan here?
> > 
> 
> (1) private_extern flags
> I intend to add this back in a follow-up before we roll DEPS.
> (2) Motion jpeg
> This was fixed upstream, so we have it :).
> http://hg.mozilla.org/mozilla-central/rev/fac849dd7be9
> (3) 6b compatibility
> Per our conversation on chat, let's reapply this, but also plan to investigate
> later.
> (4) Fixed an issue with Arm NEON build
> Thanks again for pointing this out!  I'll add it back in.  This looks like it
> could potentially be a bug in upstream.  I may follow up there.

Sounds like a plan.  Notes like these should be added to README.chromium, but to
save a re-upload, let's add what notes we need in the followup.

> > Also, does 1.4.90 have the https://crbug.com/591927 fix?
> 
> Hmm apparently not.  I've added this in.

OK that looks better.

https://codereview.chromium.org/1939823002/diff/60001/jconfig.h
File jconfig.h (right):

https://codereview.chromium.org/1939823002/diff/60001/jconfig.h#newcode15
jconfig.h:15: 
So long as we don't compile in the arithmetic coding / decoding .c files, I will
be happy.

https://codereview.chromium.org/1939823002/diff/60001/jconfig.h#newcode46
jconfig.h:46: /* #undef MEM_SRCDST_SUPPORTED */
Yes, that looks better.

https://codereview.chromium.org/1939823002/diff/60001/jdhuff.c
File jdhuff.c (left):

https://codereview.chromium.org/1939823002/diff/60001/jdhuff.c#oldcode687
jdhuff.c:687: r = s >> 4;
slow_decode_mcu looks good.

https://codereview.chromium.org/1939823002/diff/60001/jdhuff.h
File jdhuff.h (right):

https://codereview.chromium.org/1939823002/diff/60001/jdhuff.h#newcode229
jdhuff.h:229: goto slowlabel; \
Yes, looks good.

[Noel Gordon, 2016-05-04 15:57:04]

LGTM

Suggest you land on the following bugs to help with the followups.
 
BUG=608347,398235,591927

[msarett, 2016-05-04 16:24:43]

Description was changed from

==========
Update to libjpeg_turbo 1.4.90

BUG=608347
==========

to

==========
Update to libjpeg_turbo 1.4.90

BUG=608347,398235,591927
==========

[msarett, 2016-05-04 17:31:35]

Landed as https://codereview.chromium.org/1953443002