kc3-lang/libjpeg-turbo

Log

Author Commit Date CI Message
DRC 04d3143a 2020-01-07T16:21:03 Merge branch 'master' into dev
DRC fdf89033 2020-01-07T15:23:08 Eliminate unnecessary NULL checks before free() This programming practice (which exists in other code bases as well) is a by-product of having used early C compilers that did not properly handle free(NULL). All modern compilers should properly handle that. Fixes #398
DRC b34c85ea 2019-12-31T01:20:12 Merge branch 'master' into dev
DRC 166e3421 2019-12-31T01:10:30 simd/arm64/jsimd_neon.S: Fix checkstyle issue
DRC c4675d62 2019-12-31T00:42:53 Merge branch 'master' into dev
DRC 6367924a 2019-12-31T00:32:30 tjTransform(): Use instance err. for bad crop spec Addresses a concern raised in #396
DRC 29f718ee 2019-12-31T00:06:11 README.md, package specs: Various tweaks - Don't enumerate the types of SIMD instructions that libjpeg-turbo supports, as this can change without notice. - Use more clear terminology when describing support for libjpeg v7/v8 features ("libjpeg" is, colloquially but not officially, the name for the IJG's software, whereas the "libjpeg API" refers to our emulation of said software.) - "PhotoShop" = "Photoshop" (StudLy Caps Police) - Adjust dynamic library versions to reflect the addition of jpeg_read_icc_profile() and jpeg_write_icc_profile() in libjpeg-turbo 2.0.x.
DRC fe50cd99 2019-12-30T23:52:34 djpeg.c: Fix compiler warning w/o mem. src manager insize is only used when the in-memory source manager is compiled in.
DRC b542e4c8 2019-12-20T13:18:23 ARMv8 SIMD: Support execute-only memory (XOM) Move constants out of the .text section in simd/arm64/jsimd_neon.S and into a .rodata section. This ensures that the ARMv8 NEON SIMD extensions are compatible with memory layouts that are marked execute-only (and thus unreadable.) Based on: https://github.com/ivanloz/libjpeg-turbo/commit/88f3ca7664fadfb5e106efecb7845753aaf330b7 Closes #318
DRC 80acd5c4 2019-12-19T10:20:52 Remove code for the obsolete RLE image format libjpeg-turbo never included that code, because it requires an external library (the Utah Raster Toolkit.) The RLE image format was supplanted by GIF in the late 1980s, so it is rarely seen these days. (It had a lousy Weissman score, anyhow.)
DRC 5000eaa3 2019-12-19T10:13:05 cdjpeg.c: Fix Visual C++ compiler warning (introduced by previous commit)
DRC e98b0612 2019-12-18T15:12:33 Add fault tolerance features to djpeg and jpegtran - Enable progress reporting at run time using a new -report argument (cjpeg now supports that argument as well) - Limit the allowable number of scans using a new -maxscans argument - Treat warnings as fatal using a new -strict argument This mainly demonstrates how to work around the two issues with the JPEG standard described here: https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf since those and similar issues continue to be erroneously reported as libjpeg-turbo bugs.
DRC 54288598 2019-12-17T15:37:50 ChangeLog.md: Document 81b8c0ee
DRC 81b8c0ee 2019-12-17T14:18:35 Loongson MMI: Merge with MIPS64/add auto-detection Modern Loongson processors are MIPS64-compatible, and MMI instructions are now supported in the mainline of GCC. Thus, this commit adds compile-time and run-time auto-detection of MMI instructions and moves the MMI SIMD extensions for libjpeg-turbo from simd/loongson/ to simd/mips64/. That will allow MMI and MSA instructions to co-exist in the same build once #377 has been integrated. Based on: https://github.com/FlyGoat/libjpeg-turbo/commit/82953ddd61549428f58066f7eff0d60ce7429865 Closes #383
DRC 52fef349 2019-12-10T19:10:55 Eliminate internal use of GETJOCTET() macro Because of 01e30323546d37792e4f682d78d58bb8b3e185ab (officially eliminating support for compilers without unsigned char, since we never effectively supported those compilers anyhow), GETJOCTET() is now a no-op. Since that macro is in jmorecfg.h, it is part of the de facto libjpeg API and must remain in the public headers. However, there is no reason to continue using it internally, and eliminating its internal use improves code readability.
mayeut e821464f 2018-04-03T12:47:54 ARM64 NEON SIMD impl. of prog. Huffman encoding This commit adds ARM64 NEON optimizations for the encode_mcu_AC_first() and encode_mcu_AC_refine() functions used in progressive Huffman encoding. Compression speedups for the typical set of five libjpeg-turbo test images (https://libjpeg-turbo.org/About/Performance): Cortex-A53: 23.8-39.2% (avg. 32.2%) Cortex-A72: 26.8-41.1% (avg. 33.5%) Apple A7: 29.7-45.9% (avg. 39.6%) Closes #229
DRC b8a7680e 2019-12-05T22:38:05 Merge branch 'master' into dev
DRC 52291467 2019-12-05T21:25:20 Travis: Use MacPorts instead of Homebrew Homebrew tends to drop support for a macOS release the second that Apple stops releasing security updates for it, and that makes HB difficult to use with some of the Travis macOS images. Furthermore, even on supported macOS releases, HB sometimes tries to build GCC from source even if a binary (bottle) is available. Long story short, MacPorts just generally has better backward compatibility. MacPorts is also what I personally use on the official libjpeg-turbo build machine.
DRC f64c5508 2019-12-05T15:39:28 Merge branch 'master' into dev
DRC c76f4a08 2019-12-05T13:12:28 Huffman enc.: Fix very rare local buffer overrun ... detected by ASan. This is a similar issue to the issue that was fixed with 402a715f82313384ef4606660c32d8678c79f197. Apparently it is possible to create a malformed JPEG image that exceeds the Huffman encoder's 256-byte local buffer when attempting to losslessly tranform the image. That makes sense, given that it was necessary to extend the Huffman decoder's local buffer to 512 bytes in order to handle all pathological cases (refer to 0463f7c9aad060fcd56e98d025ce16185279e2bc.) Since this issue affected only lossless transformation, a workflow that isn't generally exposed to arbitrary data exploits, and since the overrun did not overflow the stack (i.e. it did not result in a segfault or other user-visible issue, and valgrind didn't even detect it), it did not likely pose a security risk. Fixes #392
DRC 26b4d62a 2019-11-15T13:57:56 Merge branch 'master' into dev
DRC c0b16e3d 2019-11-15T13:29:11 TurboJPEG: Fix erroneous subsampling detection ... that caused some JPEG images with unusual sampling factors to be misidentified as 4:4:4. This led to a buffer overflow when attempting to decompress some such images using tjDecompressToYUV*(). Regression introduced by 479501b07c0afd8912a0e0f5b4740cfce9a89a4c The correct behavior is for the TurboJPEG API to refuse to decompress such images, which it did prior to the aforementioned commit. Fixes #389
DRC 6cedf37c 2019-11-15T12:36:11 ChangeLog.md: List CVE IDs for specific fixes
DRC 9c6f79e9 2019-11-13T14:36:37 Fix formatting issues detected by checkstyle
DRC f60b6dd3 2019-11-12T17:42:39 Remove vestigial jpeg_nbits_table.inc Not needed since 087c29e07f7533ec82fd7eb1dafc84c29e7870ec
DRC c43a5081 2019-11-12T17:07:46 Merge branch 'master' into dev
DRC bd20344b 2019-11-12T15:45:20 tjDecompressToYUV*(): Fix OOB write/double free ... when attempting to decompress grayscale JPEG images with sampling factors != 1. Fixes #387
DRC c30b1e72 2019-11-12T12:27:22 64-bit tjbench: Fix signed int overflow/segfault ... that occurred when attempting to decompress images with more than 715827882 (2048*1024*1024 / 3) pixels. Fixes #388
DRC 713c451f 2019-11-08T14:53:55 Enable SSE2 progressive Huffman encoder for x32 Referring to #289, I'm not sure where I arrived at the conclusion that the SSE2 progressive Huffman encoder doesn't provide any speedup for x32. Upon re-testing, I discovered it to be about 50% faster than the C encoder. This commit also re-purposes one of the CI tests (specifically, the jpeg-7 API/ABI test) so that it tests x32 as well.
DRC 2234deee 2019-11-08T13:51:34 Fix MSan use-of-uninitialized-value error ... introduced by 42825b68d570fb07fe820ac62ad91017e61e9a25. In fact, fault-tolerant multi-scan block smoothing cannot currently be used with the arithmetic decoder, because that decoder doesn't have any way of distinguishing a normal end of scan from an unexpected end of scan. Thus, this commit also modifies the change log to reset the expectations regarding the scope of the fault-tolerant multi-scan block smoothing feature. If, at some point in the future, the arithmetic decoder can be modified to detect an unexpected end of scan, then one would need only set entropy->pub.insufficient_data = TRUE when the arithmetic decoder encounters an unexpected end of scan in order to make fault-tolerant block smoothing work properly with that decoder.
DRC 82695cfd 2019-11-07T15:15:36 ChangeLog: Acknowledge 2.0.3/de-acknowledge 2.0.4 It is very unlikely that there will be an official 2.0.4 release.
DRC 42825b68 2019-11-07T14:03:23 Fault-tolerant multi-scan block smoothing This commit modifies the behavior of the block smoothing algorithm in the libjpeg API library so that, if a scan in a multi-scan JPEG image is incomplete (due to premature termination of the image stream), the block smoothing parameters from the previous (complete) scan are used to smooth any iMCU rows that the incomplete scan does not contain. Closes #343
DRC f2d4b473 2019-11-07T02:13:09 Travis: Use Docker tag that matches Git branch dcommander/buildljt:dev is a CentOS 6 container with YASM 1.2.0 rather than NASM 2.10, so it can build the new optimized SSE2 Huffman encoder.
DRC 45dff48c 2019-11-06T23:02:03 Merge branch 'master' into dev
DRC 622c462e 2019-11-06T17:24:08 Fix copyright header formatting buglets
DRC 410c028f 2019-11-06T14:17:10 example.txt: Avoid undefined setjmp() behavior Modifying a locally-defined non-volatile variable below the setjmp() return point results in undefined behavior whereby the variable may not have the expected value after setjmp() returns. Fixes #379
DRC d70047fc 2019-11-05T17:45:10 Travis: Use GCC 6 for Mac pre-release builds The primary impetus for this is to eliminate build warnings, such as (32-bit only) section "__textcoal_nt" is deprecated object file (XXXXXX.o) was built for newer OSX version (10.XX) than being linked (10.5) Upgrading to GCC 6 results in neutral performance for compression, a measured average overall decompression speedup of 2.5% for 64-bit code, and a measured average overall decompression speedup of -4.3% for 32-bit code on a 3 GHz Core i7. The 4.3% slow-down for 32-bit code is deemed acceptable, given that 32-bit macOS apps are deprecated.
DRC cbf0fcc8 2019-11-05T11:56:06 i386 SSE2 Huffman: Fix pointer arithmetic issue Splitting the pointer arithmetic in GET_SYM() into a separate add and sub instruction was an attempt to work around an error ("invalid operand type") that occurred when assembling the file with NASM. However, this created a link error on macOS ("ld: illegal text-relocation to '_jconst_huff_encode_one_block' in simd/CMakeFiles/simd.dir/i386/jchuff-sse2.asm.o from '_jsimd_huff_encode_one_block_sse2' in simd/CMakeFiles/simd.dir/i386/jchuff-sse2.asm.o for architecture i386") and also changed the alignment of the code in ways that might have affected the previous benchmark results (which took a great deal of time to obtain.) Ultimately, the path of least resistance is just to require NASM 2.13 or later.
DRC bbedb4b5 2019-11-05T15:43:21 Merge branch 'master' into dev
DRC cf54623b 2019-11-05T12:21:25 Mac: Support hiding SIMD fct symbols w/ NASM 2.14+ (NASM 2.14+ now supports the private_extern section directive, which was previously only available with YASM.)
DRC 087c29e0 2018-10-22T10:05:18 Optimize Huffman encoding This commit improves the C and SSE2 Huffman encoding implementations in the following ways: - Avoid using xmm8-xmm15 in the x86-64 SSE2 implementation. There is no actual need to use those registers, and avoiding them produces a cleaner WIN64 function entry/exit-- as well as shorter code, since REX prefixes can be avoided (this is helpful on certain CPUs, such as Intel Atom, for which instruction fetch and decoding can be a bottleneck.) - Optimize register usage so that fewer REX prefixes and register-register moves are needed. - Use the bit counter to store the number of free bits in the bit buffer rather than the number of bits in the bit buffer. This changes the method for inserting a code into the bit buffer to: (put_buffer |= code << (free_bits -= code_size)); As a result: * Only one bit counter needs to stay in a register (we just keep it in cl.) * The bit buffer contents are already properly aligned to be written out (after a byte swap.) * Adjusting the free bits counter and checking if the bit buffer is full can be combined into a single operation. * We can wait to flush the bit buffer until the buffer is actually full and not just in danger of becoming full. Thus, eight bytes can be flushed at a time. - Speed is quite sensitive to the alignment of branch target labels, so insert some padding and remove branches from the flush code. (Flushing this way isn't actually faster when compared to using branches, but the branchless code doesn't need extra alignment and is thus smaller.) - Speculatively write out the bit buffer as a single 8-byte write, falling back to a byte-by-byte write only if there are any 0xFF bytes in the bit buffer that need to be encoded as 0xFF 0x00. - Use MMX registers for the 32-bit implementation (so the bit buffer can be 64 bits wide.) - Slightly reduce overall function code size. - Eliminate or combine a few SSE instructions. - Make some minor improvements to instruction scheduling. - Adjust flush_bits() in jchuff.c to handle cases in which the bit buffer has less than 7 free bits (apparently that couldn't happen before.) Based on: https://github.com/1camper/libjpeg-turbo/commit/947a09defa2ec848322b1bae050d1b57b316a32a https://github.com/1camper/libjpeg-turbo/commit/262ebb6b816fd8a49ff4d7185f6c5153dddde02f https://github.com/1camper/libjpeg-turbo/commit/6e9a091221bb244c8ba232a942650e94254ffcf0 See change log for performance claims. Closes #292
DRC d92ae5df 2019-11-04T18:50:45 Merge branch 'master' into dev
DRC ac59b2c5 2019-11-04T18:49:46 TJBench: Fix output with -componly -quiet
DRC 6902cdb1 2019-10-28T14:28:29 Build: Don't require ASM_NASM if !REQUIRE_SIMD The build system is supposed to fall back to a non-SIMD build if WITH_SIMD==1 but REQUIRE_SIMD==0. Based on: https://github.com/emlix/libjpeg-turbo/commit/972df912d08b755db3ca60d93b058a42e97a79eb Closes #384
DRC adf9cc94 2019-10-16T20:11:59 j*huff.c: Remove crufty ASSIGN_STATE() macro This macro is a relic of libjpeg's historic need to support a wide variety of C compilers with varying degrees of compatibility. Such was necessary during the open systems era, because C compilers were often supplied by the system vendor. Prior to 1989, there was no C standard per se, and even after ANSI C became a thing, there were still compilers in use that didn't conform to it (libjpeg was first released in 1991.) Realistically, only a handful of C compilers are in widespread use these days, and all modern C compilers should support structure assignment.
DRC 95f4d6ef 2019-10-24T02:13:23 Merge branch 'master' into dev
DRC 55de9720 2019-10-24T01:50:35 AppVeyor: Use MinGW-builds instead of MSYS2 MinGW ... to avoid backward compatibility issues with GCC 4-6 MinGW toolchains. Apparently GCC 7+ MinGW toolchains introduce a link-time dependency with internal MinGW CRT functions that are meant to provide compatibility with Microsoft's Universal CRT (ucrt) library, but those internal functions are not available in GCC 4-6 MinGW toolchains. This made it impossible to use the official builds of libjpeg.a and libturbojpeg.a with GCC 4-6 MinGW toolchains (a fatal link error-- "undefined reference to '__imp___acrt_iob_func'"-- occurred.) This problem was not immediately apparent after switching to the MSYS2 implementation of MinGW (d6d7b539682abb50b04207abd21726573c0fb845) because, for a while, MSYS2 was still using GCC 5 and 6. Refer to libjpeg-turbo/libjpeg-turbo#382
DRC 708f013f 2019-10-22T20:08:57 Win packaging: Fix 64-bit VC/GCC co-install issue
DRC 163f0b19 2019-10-22T19:39:38 Bump version to 2.0.4 to prepare for new commits
DRC 3a32d199 2019-10-17T19:59:01 x86 SIMD: Consistify capitalization of NASM types byte, word, dword, qword, oword, and yword are all assembler keywords, so it makes sense to use lowercase for these so as not to mistake them for macros or constants.
DRC 9a51a87a 2019-10-17T11:21:32 x86 SIMD: Remove obsolete [TAB8] comments With apologies to Richard Hendricks, our assembly code no longer uses tabs.
DRC 74aeaddf 2019-10-16T21:16:43 jc*huff.c: Consistify preproc directive formatting The rest of the libjpeg API code uses "#if defined(condition)" rather than "#if defined condition".
DRC 2ae2bd66 2019-10-04T16:05:11 Remove support for Apple's Java implementation (AKA "Java for OS X systems.") This implementation of Java 1.6 is long obsolete and not supported on any version of macOS past High Sierra. Oracle no longer provides a 32-bit JVM on macOS, so it is no longer necessary to provide a 32-bit version of the TurboJPEG Java wrapper on macOS.
DRC b7523059 2019-10-04T15:53:30 Merge branch 'master' into dev
DRC ab6c4a5d 2019-10-04T15:02:18 Travis: Fix macOS build Java 6 has moved to homebrew/cask-versions.
DRC ec4cacc1 2019-10-02T16:35:17 BUILDING.md: Document need for CRB/PowerTools repo NASM and YASM are located in this non-default repository on (respectively) RHEL and CentOS.
DRC b4110b65 2019-09-04T18:58:12 Merge branch 'master' into dev
DRC 5db6a681 2019-08-30T12:02:50 README.md: Document memory debugger pitfalls (more specifically, the need to disable libjpeg-turbo's SIMD extensions when testing with valgrind, MSan, etc.) Addresses a concern expressed in #365
DRC f448279b 2019-08-30T11:15:47 README.md: Remove vestigial autotools references
DRC ded5a504 2019-08-15T13:24:25 tjDecodeYUV*: Fix err if TJ inst used for prog dec If the TurboJPEG instance passed to tjDecodeYUV[Planes]() was previously used to decompress a progressive JPEG image, then we need to disable the progressive decompression parameters in the underlying libjpeg instance before calling jinit_master_decompress(). This commit also modifies the build system so that the "tjtest" target will test for this issue, and it corrects a previous oversight in the build system whereby tjbenchtest did not test progressive compression/decompression unless WITH_JAVA was true.
DRC 8ef53b10 2019-08-14T22:08:59 Merge branch 'master' into dev
DRC c0d0fe86 2019-08-14T22:08:44 ChangeLog.md: Wordsmithing
DRC a81a8c13 2019-08-14T13:17:11 SSE2 SIMD: Fix prog Huffman enc. error if Sl%16==0 (regression introduced by 5b177b3cab5cfb661256c1e74df160158ec6c34e) The SSE2 implementation of progressive Huffman encoding performed extraneous iterations when the scan length was a multiple of 16. Based on: https://github.com/rouault/libjpeg-turbo/commit/bb7f1ef98305da915e581b59bd0ec2ef7bdb8468 Fixes #335 Closes #367
DRC 02f7bcdb 2019-08-13T16:03:48 Travis: Enable additional sanitizer tests - Re-purpose the non-SIMD test to test with MSan as well. - Re-purpose the ASan test to test with UBSan as well. - Use the default Travis build environment rather than specifying Ubuntu 14.04. I think I added 'dist: trusty' back when 14.04 was newer than the default, but now it's older than the default. - Enable verbose output for any unit tests that fail (so we can see the sanitizer output.)
DRC 7fbfe29c 2019-07-18T15:18:27 Merge branch 'master' into dev
DRC 5ced1f59 2019-07-18T14:25:25 Travis: Cache Homebrew downloads ... to speed up the Mac CI builds.
DRC b98ee192 2019-07-18T14:14:47 Travis: Update Homebrew/fix Mac CI build Updating Homebrew wasn't necessary when the CI build first started using the xcode8.3 image (see c8e52741fdb623698a27a4c55cf63db93c95aa14), but apparently it now is.
DRC ad8330af 2019-07-12T17:28:55 TJBench.java: Remove space in method invocation (to make checkstyle happy)
DRC b25adabc 2019-07-12T17:27:37 tjbench.c: Fix minor code formatting errors (introduced by 2a9e3bd7430cfda1bc812d139e0609c6aca0b884)
DRC 875e873f 2019-07-11T17:05:15 tjutil.c: Fix compiler warning with Visual Studio Apparently windows.h includes stdlib.h, which defines the max() and min() macros, so we need to ensure that tjutil.h is included after that.
DRC 2a9e3bd7 2019-07-11T15:30:04 TurboJPEG: Properly handle gigapixel images Prevent several integer overflow issues and subsequent segfaults that occurred when attempting to compress or decompress gigapixel images with the TurboJPEG API: - Modify tjBufSize(), tjBufSizeYUV2(), and tjPlaneSizeYUV() to avoid integer overflow when computing the return values and to return an error if such an overflow is unavoidable. - Modify tjunittest to validate the above. - Modify tjCompress2(), tjEncodeYUVPlanes(), tjDecompress2(), and tjDecodeYUVPlanes() to avoid integer overflow when computing the row pointers in the 64-bit TurboJPEG C API. - Modify TJBench (both C and Java versions) to avoid overflowing the size argument to malloc()/new and to fail gracefully if such an overflow is unavoidable. In general, this allows gigapixel images to be accommodated by the 64-bit TurboJPEG C API when using automatic JPEG buffer (re)allocation. Such images cannot currently be accommodated without automatic JPEG buffer (re)allocation, due to the fact that tjAlloc() accepts a 32-bit integer argument (oops.) Such images cannot be accommodated in the TurboJPEG Java API due to the fact that Java always uses a signed 32-bit integer as an array index. Fixes #361
DRC f37b7c1f 2019-07-02T11:28:26 Build: Fix build/install with Xcode IDE Closes #355
Jonathan Wright 509c2680 2019-05-09T13:46:53 Use bias pattern for 4:4:0 (h1v2) fancy upsampling This commit modifies h1v2_fancy_upsample() so that it uses an ordered dither pattern, similar to that of h2v1_fancy_upsample(), rounding up or down the result for alternate pixels rather than always rounding down. This ensures that the decompression error pattern for a 4:4:0 JPEG image will be similar to the rotated decompression error pattern for a 4:2:2 JPEG image. Thus, the final result will be similar regardless of whether a 4:2:2 JPEG image is rotated or transposed before or after decompression. Closes #356
DRC ec5adb83 2019-05-18T17:58:50 Build/packaging: Support macOS package/DMG signing
DRC 051f4862 2019-05-09T20:46:18 Travis: Fix iOS build The new libjpeg-turbo 2.1.x official build scripts expect Xcode to be under /Applications/Xcode83.app.
DRC c055c880 2019-05-09T20:36:51 Discontinue support for 32-bit iOS builds
DRC 85d96d44 2019-05-09T19:13:39 Merge branch 'master' into dev
DRC c8e52741 2019-05-09T09:11:09 Travis: Use xcode8.3 image xcode7.3 is based on El Capitan, which is EOL, and Homebrew no longer provides El Cap bottles (pre-compiled binaries.) Thus, Homebrew was trying to build GCC 5, YASM, and the other packages we need from source, which caused the Mac CI builds to time out. I tried goading Homebrew into installing GCC 5.5.0_2 and YASM 1.3.0_1, which still have El Cap bottles available, by using the URLs of those specific versions of the formulae (from the Homebrew GitHub repository) as package names. This failed, however, because 'brew bundle' converted the URLs to all lowercase. I then tried explicitly installing the old formulae by using 'brew install' with the aforementioned URLs (bypassing the Travis Homebrew addon), but Homebrew still tried to build all of the dependencies from source. Upgrading to Xcode 8.3.x necessitated regression testing the performance on iOS, but that proved less of a pain than figuring out how to install all of the old Homebrew bottles we needed. Also, this future-proofs the CI builds against the inevitable discontinuation of the xcode7.3 image. Note that Xcode 8.3.x improves iOS 64-bit decompression performance significantly relative to Xcode 7.2.x or 7.3.x. iOS 32-bit performance unfortunately regresses by as much as 5%, but it can't be helped (32-bit iOS apps are no longer supported on iOS 11+ anyhow, and the next major release of libjpeg-turbo will remove support for them as well.)
DRC f36d5315 2019-04-23T14:54:23 Merge branch 'master' into dev
DRC 6399d0a6 2019-04-23T14:10:04 Fix code formatting/style issues ... ... including, but not limited to: - unused macros - private functions not marked as static - unprototyped global functions - variable shadowing (detected by various non-default GCC 8 warning options)
Chris Blume aa9db616 2019-04-15T17:55:47 x86 SIMD: Check for CPUID leaf 07H before using According to Intel's manual [1], "If a value entered for CPUID.EAX is higher than the maximum input value for basic or extended function for that processor then the data for the highest basic information leaf is returned." Right now, libjpeg-turbo doesn't first check that leaf 07H is supported before attempting to use it, so the ostensible AVX2 bit (Bit 05) of the CPUID result might actually be Bit 05 from a lower leaf. That bit might be set, even if the CPU doesn't support AVX2. This commit modifies the x86 and x86-64 SIMD feature detection code so that it first checks whether CPUID leaf 07H is supported before attempting to use it to check for AVX2 instruction support. DRC: This commit should fix https://bugzilla.mozilla.org/show_bug.cgi?id=1520760 However, I have not personally been able to reproduce that issue, despite using a Nehalem (pre-AVX2) CPU on which the maximum CPUID leaf has been limited via a BIOS setting. Closes #348 [1] "Intel® 64 and IA-32 Architectures Software Developer's Manual, Volume 2 (2A, 2B, 2C & 2D): Instruction Set Reference, A-Z", https://software.intel.com/sites/default/files/managed/a4/60/325383-sdm-vol-2abcd.pdf, page 3-192.
DRC 8a0e35b2 2019-04-15T13:41:45 Merge branch 'master' into dev
DRC 2b05d47b 2019-04-15T13:38:15 ChangeLog.md: Document 33011754
DRC 7bc9fca4 2019-04-12T09:07:35 jdhuff.c: Silence UBSan signed int overflow err #2 Same as d3a3a73f64041c6a6905faf6f9f9832e735fd880 but in the fast decode path. It was necessary to use a different-sized test image in order to trigger the error in this location. Refer to #347
DRC bb16b944 2019-04-12T08:53:45 GitHub: Remove new lines from feature-request.md (to make checkstyle happy)
DRC 33011754 2019-04-12T08:47:28 Android: Fix "using JNI after critical get" errors 5ea77d8b771bf7b0be7acc7fb70c255f8c9c8f77 was insufficient to fix all of these. In particular, we need to always release the primitive arrays before throwing an exception, because throwing an exception qualifies as "using JNI." Refer to #300
DRC bce58f48 2019-04-12T07:49:35 Consistify formatting of macros in TurboJPEG code
DRC ce067a6c 2019-04-10T15:16:55 GitHub: Template tweaks CONTRIBUTING.md: Correct misuse of "as such" (Grammar Police) bug-report.md: Clarify that the submitter should always test against the latest stable code base.
DRC d3a3a73f 2019-04-10T14:28:47 jdhuff.c: Silence UBSan signed int overflow error Some pathological test images have been created that can cause s to overflow or underflow the signed int data type during decompression. This is technically undefined behavior according to the C spec, although every modern implementation I'm aware of will treat the signed int as a 2's complement unsigned int, thus causing the value to wrap around to INT_MIN if it exceeds INT_MAX. This commit simply makes that behavior explicit in order to shut up UBSan. At least when building for x86-64 or i386 using Clang or GCC, this commit does not change the compiler-generated assembly code at all. The code that triggered this error has existed in the libjpeg code base for at least 20 years (and probably much longer), so the fact that it hasn't produced a user-visible problem in all of that time strongly suggests that UBSan is being overly pedantic here. But if someone can cough up a platform that doesn't wrap around to INT_MIN when 1 is added to INT_MAX, then I'll happily change my opinion. Fixes #347
DRC 58a3975e 2019-04-10T14:35:45 Bump version to 2.0.3 to prepare for new commits
DRC 5857929f 2019-03-05T17:48:20 GitHub: Formatting tweak to CONTRIBUTING.md
DRC 70947727 2019-03-01T13:13:27 GitHub: Tweak bug report template
DRC 1af712c1 2019-03-01T13:11:11 GitHub: Add feature request template
DRC ec90cd0f 2019-03-01T12:29:41 GitHub: Add contributor guidelines
DRC ce76ffac 2019-03-01T10:07:51 GitHub: Add bug report template
DRC afbe48c2 2019-02-27T13:05:58 MMI: Support 32-bit Loongson architectures
DRC 98ff5507 2019-02-27T13:17:35 MMI: Fix bug in jsimd_h2v1_merged_upsample_mmi() ... that occurred when ((image width) & 1) != 0.
DRC 3ca6dba9 2019-02-17T09:33:57 Merge branch 'master' into dev
DRC 500b5ece 2019-02-17T09:06:42 turbojpeg.c: Fix compiler warning w/ -DNO_GETENV
DRC 87ab3360 2019-02-14T10:01:16 appveyor.yml: Cache NASM binary package ... since www.nasm.us seems to be down frequently. This doesn't help us at the moment, but hopefully once the site is back up this will prevent future build failures.
kmx.io     mail     discord kmxgit v0.4.0