|
3202feb0
|
2024-02-29T16:10:20
|
|
x86-64 SIMD: Support CET if C compiler enables it
- Detect at configure time, via the __CET__ C preprocessor macro,
whether the C compiler will include either indirect branch tracking
(IBT) or shadow stack support, and define a NASM macro (__CET__) if
so.
- Modify the x86-64 SIMD code so that it includes appropriate endbr64
instructions (to support IBT) and an appropriate .note.gnu.property
section (to support both IBT and shadow stack) when __CET__ is
defined.
Closes #350
|
|
|
36c51dd3
|
2024-01-26T15:55:19
|
|
GitHub: Update checkout, AWS credentials actions
... to silence deprecation warning regarding Node.js 12 and 16 actions.
|
|
|
da48edfc
|
2023-10-09T14:13:55
|
|
jchuff.c: Fix uninit read w/ AArch64, WITH_SIMD=0
Because of bf01ed2fbc02c15e86f414ff4946b66b4e5a00f1, the simd field in
huff_entropy_encoder (and, by extension, the simd field in
savable_state) is only initialized if WITH_SIMD is defined. Due to an
oversight, the simd field in savable_state was queried in flush_bits()
regardless of whether WITH_SIMD was defined. In most cases, both
branches of the query have identical code, and the optimizer removes the
branch. However, because the legacy Neon GAS Huffman encoder uses the
older bit buffer logic from libjpeg-turbo 2.0.x and prior (refer to
087c29e07f7533ec82fd7eb1dafc84c29e7870ec), the branches do not have
identical code when building for AArch64 with NEON_INTRINSICS undefined
(which will be the case if WITH_SIMD is undefined.) Thus, if
libjpeg-turbo was built for AArch64 with the SIMD extensions disabled
at build time, it was possible for the Neon GAS branch in flush_bits()
to be taken, which would have set put_bits to a value that is incorrect
for the C Huffman encoder. Referring to #728, a user reported that this
issue sometimes caused libjpeg-turbo to generate bogus JPEG images if it
was built for AArch64 without SIMD extensions and subsequently used
through the Qt framework. (It should be noted, however, that disabling
the SIMD extensions in AArch64 builds of libjpeg-turbo is inadvisable
for performance reasons.)
I was unable to reproduce the issue on Linux/AArch64 using libjpeg-turbo
alone, despite testing various versions of GCC and Clang and various
optimization levels. However, the issue is reproducible using MSan with
-O0, so this commit also modifies the GitHub Actions workflow so that
compiler optimization is disabled in the linux-msan job. That should
prevent the issue or similar issues from re-emerging.
Fixes #728
|
|
|
2c97a1ff
|
2023-10-03T12:07:40
|
|
GitHub: Use Ubuntu 20.04 runner for x32 build/test
The Ubuntu 22.04 kernel no longer supports the x32 ABI.
|
|
|
65a85ce3
|
2023-06-16T11:16:08
|
|
GitHub: Fix x32 build
1f55ae7b0fa3acc348a630171617d0e56d922b68 accidentally overrode the value
of CMAKE_C_FLAGS, thus eliminating the -mx32 flag that was necessary to
enable x32.
|
|
|
7ab6222c
|
2023-01-20T14:09:25
|
|
Merge branch 'main' into dev
|
|
|
0738305e
|
2023-01-20T13:41:25
|
|
GitHub: Update to actions/checkout@v3
... to silence deprecation warning regarding Node.js 12 actions.
|
|
|
b5a9ef64
|
2022-11-13T13:00:26
|
|
Don't allow 12-bit JPEG support to be disabled
In libjpeg-turbo 2.1.x and prior, the WITH_12BIT CMake variable was used
to enable 12-bit JPEG support at compile time, because the libjpeg API
library could not handle multiple JPEG data precisions at run time. The
initial approach to handling multiple JPEG data precisions at run time
(7fec5074f962b20ed00b4f5da4533e1e8d4ed8ac) created a whole new API,
library, and applications for 12-bit data precision, so it made sense to
repurpose WITH_12BIT to allow 12-bit data precision to be disabled.
e8b40f3c2ba187ba95c13c3e8ce21c8534256df7 made it so that the libjpeg API
library can handle multiple JPEG data precisions at run time via a
handful of straightforward API extensions. Referring to
6c2bc901e27b047440ed46920c4d3f0480b48268, it hasn't been possible to
build libjpeg-turbo with both forward and backward libjpeg API/ABI
compatibility since libjpeg-turbo 1.4.x. Thus, whereas we retain full
backward API/ABI compatibility with libjpeg v6b-v8, forward libjpeg
API/ABI compatibility ceased being realistic years ago, so it no longer
makes sense to provide compile-time options that give a false sense of
forward API/ABI compatibility by allowing some (but not all) of our
libjpeg API extensions to be disabled. Such options are difficult to
maintain and clutter the code with #ifdefs.
|
|
|
fdfba495
|
2022-09-02T15:11:25
|
|
Merge branch 'main' into dev
|
|
|
c5db99e1
|
2022-09-02T14:48:58
|
|
GitHub Actions: Specify Big Sur for macOS build
The Catalina hosted runner is now fully deprecated.
|
|
|
82081337
|
2022-04-06T11:16:09
|
|
Merge branch 'main' into dev
|
|
|
5c8cac97
|
2022-04-06T10:51:58
|
|
CI: Un-integrate CIFuzz
Referring to the conversation in
https://github.com/google/oss-fuzz/issues/7479 and #559, there was a
misunderstanding regarding how CIFuzz works. It cannot be used to fuzz
arbitrary PRs or code branches, and it has a 90-day delay in downloading
corpora from OSS-Fuzz. That makes it unsuitable for libjpeg-turbo.
|
|
|
1b9edb5c
|
2022-03-10T23:57:11
|
|
Build: Fix 12-bit FP tests w/ 32-bit builds
With x86-64 builds, the default value of FLOATTEST works with both the
8-bit-per-sample and 12-bit-per-sample flavors of the libjpeg API
library. However, that is not the case with x86 builds. Thus, we need
separate 8-bit-per-sample and 12-bit-per-sample FLOATTEST variables.
|
|
|
ebd19302
|
2022-03-10T23:21:55
|
|
GitHub Actions: "linux-12bit" --> "linux-no12bit"
This job tests the non-default value of WITH_12BIT, which is now 0
instead of 1.
|
|
|
7fec5074
|
2022-03-08T12:34:11
|
|
Support 8-bit & 12-bit JPEGs using the same build
Partially implements #199
This commit also implements a request from #178 (the ability to compile
the libjpeg example as a standalone program.)
|
|
|
da41ab94
|
2022-01-06T12:57:26
|
|
GitHub Actions: Specify Catalina for macOS build
macos-latest now maps to the Big Sur image, which doesn't have Xcode
12.2 installed.
|
|
|
1f55ae7b
|
2022-01-06T12:08:46
|
|
Fix -Wpedantic compiler warnings
... and test for those warnings (and others) when performing CI builds.
|
|
|
5446ff88
|
2021-11-19T13:43:36
|
|
CI: CIFuzz integration
CIFuzz runs the project's fuzzers for a limited period of time any time
a commit is pushed or a PR is submitted. This is not intended to
replace OSS-Fuzz but rather to allow us to more quickly catch some
fuzzing failures, including fuzzer build regressions like the one
introduced in ecf021bc0d6f435daacff7c35ccaeef0145df1b9.
Closes #559
|
|
|
4c5fa566
|
2021-11-17T16:09:50
|
|
CI: Halt immediately on all sanitizer errors
|
|
|
c23672ce
|
2021-04-23T13:05:25
|
|
GitHub Actions: Don't build tags
Our workflow script does not currently work with tags, and there is no
point to building tags anyhow, since we do not use the CI system to spin
official builds.
|
|
|
944f5915
|
2021-01-08T12:41:02
|
|
Migrate from Travis CI to GitHub Actions
Note that this removes our ability to regression test the Armv8 and
PowerPC SIMD extensions, effectively reverting
a524b9b06be2e0c24d8abc6528cf29316cfe8dc5 and
02227e48a990911a6da35ab8034911a9fbc1055a, but at the moment, there is no
other way.
|