Age | Commit message (Collapse) | Author |
|
am: 2e02f5320b
Change-Id: Ideb1d705763b1a01213bf7c9b51d0898a5aea1c1
|
|
am: e7bf3c56ca
Change-Id: I12a68697d2613363aeff1af6277f3ded73030b34
|
|
In the AArch64 ABI, the high (unused) DWORD of a 32-bit argument's
register is undefined, so it was incorrect to use 64-bit
instructions to transfer a JDIMENSION argument in the 64-bit NEON SIMD
functions. The code worked thus far only because the existing compiler
optimizers weren't smart enough to do anything else with the register in
question, so the upper 32 bits happened to be all zeroes.
The latest builds of Clang/LLVM have a smarter optimizer, and under
certain circumstances, it will attempt to load-combine adjacent 32-bit
integers from one of the libjpeg structures into a single 64-bit integer
and pass that 64-bit integer as a 32-bit argument to one of the SIMD
functions (which is allowed by the ABI, since the upper 32 bits of the
32-bit argument's register are undefined.) This caused the
libjpeg-turbo regression tests to crash.
This patch tries to use the Wn registers whenever possible. Otherwise,
it uses a zero-extend instruction to avoid using the upper 32 bits of
the 64-bit registers, which are not guaranteed to be valid for 32-bit
arguments.
Based on sebpop@1fbae13
Closes #91. Refer also to android-ndk/ndk#110 and
https://llvm.org/bugs/show_bug.cgi?id=28393
BUG:31780857
Change-Id: Id80143ac13ba8d427196daf04f00be2214f85c86
|
|
am: 0196951d06
Change-Id: Ia5a941dfd566dca7df1c392a8e01ec3cb593e082
|
|
am: b777cd4e02
Change-Id: I80c451da5572db2d1b84964beed940f5493c8231
|
|
am: 42d044c63d
Change-Id: I0c59adabbc7c3540954dbb2d72d62c43ec89b5a1
|
|
Due to the order in which jconfig.h was included in
jinclude.h, __WORDSIZE was not yet defined, so that
SIZEOF_SIZE_T was always defined as 4 even on 64bit architectures.
Also jinclude.h and jconfig.h had no include guard and where
included more than once which lead to redefinitions of the
SIZEOF_SIZE_T macro.
This patch
* makes SIZEOF_SIZE_T defined as __SIZEOF_SIZE_T__, which is predefined
by the compiler,
* makes the preprocessor emit an error if __SIZEOF_SIZE_T__ is not
predefined, and
* adds an include guard to jconfig.h.
(cherrypick of b4ab00215cfc72d42f6e19684fa7375203b2f675.)
Change-Id: Icb029a6faafdc847e2b735bd9adb465868f1b17d
|
|
(unused) DWORD of a 32-bit argument\'s register is undefined, so it was incorrect to use 64-bit instructions to transfer a JDIMENSION argument in the 64-bit NEON SIMD functions. The code worked thus far only because the existing compiler optimizers weren\'t smart enough to do anything else with the register in question, so the upper 32 bits happened to be all zeroes.
am: 938931bcd1
Change-Id: Ied40cf33c80019bf64657a745c46334bdeb1a59c
|
|
In the AArch64 ABI, the high (unused) DWORD of a 32-bit argument's
register is undefined, so it was incorrect to use 64-bit
instructions to transfer a JDIMENSION argument in the 64-bit NEON SIMD
functions. The code worked thus far only because the existing compiler
optimizers weren't smart enough to do anything else with the register in
question, so the upper 32 bits happened to be all zeroes.
The latest builds of Clang/LLVM have a smarter optimizer, and under
certain circumstances, it will attempt to load-combine adjacent 32-bit
integers from one of the libjpeg structures into a single 64-bit integer
and pass that 64-bit integer as a 32-bit argument to one of the SIMD
functions (which is allowed by the ABI, since the upper 32 bits of the
32-bit argument's register are undefined.) This caused the
libjpeg-turbo regression tests to crash.
This patch tries to use the Wn registers whenever possible. Otherwise,
it uses a zero-extend instruction to avoid using the upper 32 bits of
the 64-bit registers, which are not guaranteed to be valid for 32-bit
arguments.
Based on sebpop@1fbae13
Closes #91. Refer also to android-ndk/ndk#110 and
https://llvm.org/bugs/show_bug.cgi?id=28393
(cherrypick of c8282be605a139b269f2b8f4b4fb6f4118e740ab.)
Change-Id: Id80143ac13ba8d427196daf04f00be2214f85c86
|
|
am: 48a5ae8abb
Change-Id: I74b06fd922a290790d5e7c7840e0968a0493c352
|
|
am: 21f73d8ee6
Change-Id: Ic4b22abc8ec880699721428ef5fc23153cb0668a
|
|
Change-Id: I9b24c54b0af96ed0fc0886a42657762a055a8871
|
|
|
|
The accelerated Huffman decoder was previously invoked if there were
> 128 bytes in the input buffer. However, it is possible to construct a
JPEG image with Huffman blocks > 430 bytes in length
(http://stackoverflow.com/questions/2734678/jpeg-calculating-max-size).
While such images are pathological and could never be created by a
JPEG compressor, it is conceivable that an attacker could use such an
artifially-constructed image to trigger an input buffer overrun in the
libjpeg-turbo decompressor and thus gain access to some of the data on
the calling program's heap.
This patch simply increases the minimum buffer size for the accelerated
Huffman decoder to 512 bytes, which should (hopefully) accommodate any
possible input.
This addresses a major issue (LJT-01-005) identified in a security audit
by Cure53.
Cherry picked from upstream:
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/0463f7c9aad060fcd56e98d025ce16185279e2bc
BUG:27494207
BUG:27480923
Change-Id: I94876fecafa8b7d7f31734cb21d2ca0f382802ec
|
|
This prevents a malformed motion-JPEG frame (MJPEG frames lack Huffman
tables) from causing the "fast path" of the Huffman decoder to read
uninitialized memory. Essentially, this is doing the same thing for
MJPEG frames as 43d8cf4d4572fa50a37cccadbe71b9bee37de55d did for regular
images.
Cherry picked from upstream:
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/a572622dd654305c86585724c2a1ea34e22c2103
BUG:27494207
BUG:27480923
Change-Id: I91f334b82290b009bc624b3d5f8a9b3021f34ea0
|
|
This, in combination with the existing jpeg_skip_scanlines() function,
provides the ability to crop the image both horizontally and vertically
while decompressing (certain restrictions apply-- see libjpeg.txt.)
This also cleans up the documentation of the line skipping feature and
removes the "strip decompression" feature from djpeg, since the new
cropping feature is a superset of it.
Refer to #34 for discussion.
Closes #34
Cherry picked from upstream:
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/3ab68cf563f6edc2608c085f5c8b2d5d5c61157e
BUG:27290496
Change-Id: Id11312fa43959531bc6bea04ebb657c6e1140363
|
|
This provides ~2.5x speed-up on full image decodes.
BUG:25815224
BUG:25641008
Change-Id: I3ce188d371c5e41ebc810dbc810ac460be3b5074
|
|
Change-Id: I78a73665923db7200aaff7c5a9c0da8f7ac4a58e
|
|
|
|
This directive was preventing the code from assembling using the
integrated assembler in clang.
Fixes Upstream-Issue-33
https://github.com/libjpeg-turbo/libjpeg-turbo/issues/33
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/d70a5c12fcb72443483456a2cc8dd18a4c238618
Change-Id: I9e361d509be759cd45ed8d8061f939059ad5fe4a
|
|
We have cherry-picked a fix from upstream so that the assembly is
now clang compatible.
BUG:25564571
Change-Id: Ic4a676b8648e5bc83e3a1da1f346ec2f5cc953ac
|
|
This is a workaround for
https://buganizer.corp.google.com/u/0/issues/26023491
libjpeg.so has text relocations.
BUG:26023491
Change-Id: I54cf63479a23fe5cbf2ecce97781cbb1110a46b3
|
|
|
|
Change-Id: I9422d03fbde8061619c52f4202fd0fa7dd12fe5a
|
|
BUG:25685061
Change-Id: I7a7710ed7d1320fac2062d83eba4a230de92e10c
|
|
|
|
I must have accidentally dropped this line from the previous
commit:
https://googleplex-android-review.git.corp.google.com/#/c/818568/
Change-Id: I0c19a01bdd588a88e13acfdea6df299dd839f780
|
|
|
|
Change-Id: I2aa903ea44cc3da9255543dd21a312e3dd410b8c
|
|
Because we have switched to the latest release from upstream,
we no longer need these chromium specific files.
Change-Id: Ibca796ddc3479671432afcd0c1d91def4d661cdc
|
|
BUG:23138693
BUG:25685061
|
|
|
|
|
|
When using context-based upsampling, use a dummy color conversion
routine instead of a dummy row buffer. This improves performance
(since the actual color conversion routine no longer has to be called),
and it also fixes valgrind errors when decompressing to RGB565.
Valgrind previously complained, because using the RGB565 color
converter with the dummy row buffer was causing a table lookup with
undefined indices.
|
|
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1591 632fc199-4ca6-4c93-a231-07263d6284db
|
|
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1589 632fc199-4ca6-4c93-a231-07263d6284db
|
|
Studio.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1588 632fc199-4ca6-4c93-a231-07263d6284db
|
|
in djpeg; document -strip and -skip parameters in djpeg
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1587 632fc199-4ca6-4c93-a231-07263d6284db
|
|
jpeg_skip_scanlines() function + remove comment that is no longer relevant.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1586 632fc199-4ca6-4c93-a231-07263d6284db
|
|
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1583 632fc199-4ca6-4c93-a231-07263d6284db
|
|
partially decoding a JPEG image.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1582 632fc199-4ca6-4c93-a231-07263d6284db
|
|
This new name matches the name of external/jpeg.
This will make it easier to replace external/jpeg with this
library.
Change-Id: Iceaea74c2ca2cd0e6484526ae7281ba39f9d198e
|
|
We still need to disable the clang assembler for ARM v8 devices.
BUG:25564571
Change-Id: I8bf3b3a6a9efd1f761811b5829680746a095c151
|
|
Change-Id: Ic6cda8ac02fefec110f0c6270313449589471b49
|
|
For now we can get around the compile problems by using gcc.
We should follow up with clang to see about fixing these issues.
BUG:25564571
Change-Id: I573e02b19aaa4c3e59e4bd287502068cda49efb4
|
|
Change-Id: Ia2b983a15a7fc12d0f47c338f831d5de6e8de75b
|
|
Change-Id: I34d559da7f68fe10ec7aaa72e555626a7be75e72
|
|
Change-Id: Idd23e749fef193ee5ddaba02dad88939c5755ad3
|
|
Change-Id: Ieb73e8913a0902eea36b43e870337aa06de19a5f
|
|
BUG:25424175
BUG:23138693
Change-Id: I12314248a5c636bca0d69585dfb470ec656d0373
|