Merge branch 'master' into dev

TJBench: Code formatting tweaks

Spaces-->tab + remove stray control character that was introduced in
95e4cb206085c3a715f0f017c174fdf367a2c1ff

TJBench: Fix errors when decomp. files w/ ICC data

Embedded ICC profiles can cause the size of a JPEG file to exceed the
size returned by tjBufSize() (which is really meant to be used for
compression anyhow, not for decompression), and this was causing a
segfault (C) or an ArrayIndexOutOfBoundsException (Java) when
decompressing such files with TJBench.  This commit modifies the
benchmark such that, when tiled decompression is disabled, it re-uses
the source buffer as the primary JPEG buffer.

BUILDING.md: Include Android/x86 build recipes

Addresses a concern raised in #155.

Travis: Fix OS X build

The Travis xcode7.3 image now apparently includes GnuPG 1.4.x by
default, so use it instead of installing GnuPG 2.  Using GnuPG 2.1.x,
the default version in Homebrew as of this writing, is problematic for
this reason:
https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase

Restore compatibility with older autoconf releases

(broken by f06cc1200fd5f61b63479d7099ccf4a7457a89bd)

Fixes #149

Attribute ARM runtime detection code to Nokia

This code was submitted in the initial ARM NEON patches
(https://sourceforge.net/p/libjpeg-turbo/patches/7/) by Siarhei while he
was still a Nokia employee.

Honor max_memory_to_use/JPEGMEM/-maxmemory

This re-introduces a feature of the obsolete system-specific libjpeg
memory managers-- namely the ability to limit the amount of main memory
used by the library during decompression or multi-pass compression.
This is mainly beneficial for two reasons:

- Works around a 2 GB limit in libFuzzer
- Allows security-sensitive applications to set a memory limit for the
  JPEG decoder so as to work around the progressive JPEG exploit
  (LJT-01-004) described here:
  http://www.libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf

This commit also removes obsolete documentation regarding the MS-DOS
memory manager (which itself was removed long ago) and changes the
documentation of the -maxmemory switch and JPEGMEM environment variable
to reflect the fact that backing stores are never used in libjpeg-turbo.

Inspired by:
https://github.com/caolanm/libjpeg-turbo/commit/066fee2e7d6834f24838bc1896aa38ca77209e3c

Closes #143

AppVeyor: Fix CI build

Something changed in the CI build environment, and our previous trick of
setting the Git URL to file://c:/projects/libjpeg-turbo no longer works.
Using cygpath to translate the Windows path to a MinGW-friendly format
is a better solution anyhow.

TurboJPEG: Fix potential memory leaks

Referring to https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=746,
it seems that the values of local buffer pointers in TurboJPEG API
functions aren't always preserved if longjmp() returns control to a
point prior to the allocation of the local buffers.  This is known to
be an issue with GCC 4.x and clang with -O1 and higher optimization
levels but not with GCC 5.x and later.  It is unknown why GCC 5.x and
6.x do not suffer from the issue, but possibly the local buffer pointers
are not allocated on the stack when using those more recent compilers.

In any case, this commit modifies the TurboJPEG API library code such
that the jump buffer is always updated after any local buffer pointers
are allocated but before any subsequent libjpeg API functions are
called.

libjpeg API: Support reading/writing ICC profiles

This commit does the following:

-- Merges the two glueware functions (read_icc_profile() and
write_icc_profile()) from iccjpeg.c, which is contained in downstream
projects such as LCMS, Ghostscript, Mozilla, etc.  These functions were
originally intended for inclusion in libjpeg, but Tom Lane left the IJG
before that could be accomplished.  Since then, programs and libraries
that needed to embed/extract ICC profiles in JPEG files had to include
their own local copy of iccjpeg.c, which is suboptimal.

   -- The new functions were prefixed with jpeg_ and split into separate
   files for the compressor and decompressor, per the existing libjpeg
   coding standards.

   -- jpeg_write_icc_profile() was made slightly more fault-tolerant.
   It will now trigger a libjpeg error if it is called before
   jpeg_start_compress() or if it is passed NULL arguments.

   -- jpeg_read_icc_profile() was made slightly more fault-tolerant.
   It will now trigger a libjpeg error if it is called before
   jpeg_read_header() or if it is passed NULL arguments.  It will also
   now trigger libjpeg warnings if the ICC profile data is corrupt.

   -- The code comments have been wordsmithed.

   -- Note that the one-line setup_read_icc_profile() function was not
   included.  Instead, libjpeg.txt now documents the need to call
   jpeg_save_markers(cinfo, JPEG_APP0 + 2, 0xFFFF) prior to calling
   jpeg_read_header(), if jpeg_read_icc_profile() is to be used.

-- Adds documentation for the new functions to libjpeg.txt.

-- Adds an -icc switch to cjpeg and jpegtran that allows those programs
to embed an ICC profile in the JPEG files they generate.

-- Adds an -icc switch to djpeg that allows that program to extract an
ICC profile from a JPEG file while decompressing.

-- Adds appropriate unit tests for all of the above.

-- Bumps the SO_AGE of the libjpeg API library to indicate the presence
of new API functions.

Note that the licensing information was obtained from:
https://github.com/mm2/Little-CMS/issues/37#issuecomment-66450180

Remove vestigial license text regarding autoconf

Merge branch 'master' into dev

Always tweak EXIF w/h tags w/ lossless transforms

... even if using libjpeg v6b emulation.  Previously
adjust_exif_parameters() was only called with libjpeg v7/v8 emulation,
but due to a bug (which this commit also fixes), it only worked properly
with libjpeg v8 emulation.

Fix error w/ lossless crop & libjpeg v7 emulation

The JPEG_LIB_VERSION #ifdef in jtransform_adjust_parameters() was
incorrect, which caused a "Bogus virtual array access" error when
attempting to use the lossless crop feature.

Introduced in c04bd3cc97f44fd9030de1e141754c8775d4e5a5.

This also adds libjpeg v7 API/ABI emulation to the Travis CI tests.

Include jpeg_skip/crop_scanlines() in jpeg7.dll

... when the in-memory source/destination managers are included.
Oversight in 306e1d2d778cf5a4d2a22ac847a31722b9fc2845 and
3ab68cf563f6edc2608c085f5c8b2d5d5c61157e.

libjpeg.txt: Include partial decomp. in TOC

(oversight)

Slightly de-confusify cjpeg, jpegtran usage info

+ bump copyright year

BUILDING.md: Documentation buglet

`make cygwinpkg` was listed under "Mac".

Merge branch 'master' into dev

LICENSE.md: Include text of BSD/zlib licenses

LICENSE.md is included in the binary distributions as well, so it
doesn't make much sense to refer to license headers in source files that
aren't necessarily going to be there.

Packaging system: "PACKAGE_NAME" = "PKGNAME"

Using PACKAGE_NAME as a variable name made more sense with autotools,
but now it's more of an inconvenience variable than a convenience
variable.

Build: Don't require sudo for `make tarball`

The whole point of `make tarball` is to make it easy for users to create
a binary distribution of libjpeg-turbo on platforms that aren't
supported by our official build system, so requiring root permissions
somewhat defeated that purpose.  Intead, the script now attempts to
detect whether the system has GNU tar or a recent version of BSD tar
that supports setting the ownership of the files in the tarball.

Mac pkg: Use PKGNAME for documentation directory

Although there is little chance that we will ever have a package
conflict on OS X, the convention from our Linux packages is to use the
package name, not the project name, for the name of the documentation
directory.

Build: More GNUInstallDirs improvements

These improvements enable build systems to use GNUInstallDirs to define
custom directory variables.

- The set_dir() macro was renamed to GNUInstallDirs_set_install_dir(),
  in keeping with the module's established macro naming convention.

- Rather than detecting whether the prefix has changed, the new
  GNUInstallDirs_set_install_dir() macro instead examines whether the
  default for the variable in question has changed.  This allows for
  more flexibility, since build systems may decide to change the
  defaults based on factors other than the prefix.  It also enables the
  macro to work properly outside of the module.

- The module now performs directory variable substitution within the
  body of GNUInstallDirs_get_absolute_install_dir().

- The JAVADIR variable is no longer included in GNUInstallDirs.  That
  directory is not part of the GNU spec, and it turns out that various
  operating systems use different conventions for the location of Java
  classes.  Instead, the variable is now implemented in our build
  system as a demonstration of the aforementioned GNUInstallDirs
  enhancements.

Build: Various improvements to install/pkg system

- GNUInstallDirs: any directory variable can now reference any other
  directory variable by including its name in angle brackets (<>).

- Changed the documentation of the directory variables in BUILDING.md
  accordingly.  This commit also includes some formatting tweaks to
  that section (using boldface for directory names, as is our
  convention.)

- Changed the package scripts such that they use
  CMAKE_INSTALL_DATAROOTDIR rather than CMAKE_INSTALL_DATADIR.

- We no longer override the install dir. defaults on Windows unless
  performing an official build.  It may be useful, for instance, to
  use the GNU defaults when installing into an MSYS environment.

Build: Minor tweaks to GNUInstallDirs defaults

It isn't actually necessary to specify `CMAKE_INSTALL_DEFAULT_MANDIR`
for our official build.  Because `CMAKE_INSTALL_DEFAULT_DATAROOTDIR` is
blank for the official build, the default of "<DATAROOTDIR>/man" will
resolve to "man".

For the same reason, this commit changes the specification of
`CMAKE_INSTALL_DEFAULT_DOCDIR` and `CMAKE_INSTALL_DEFAULT_JAVADIR` in
the official build to be dependent on the data root directory (mainly to
make it obvious what we're doing.)

This commit also tweaks the example CMake command line in the directory
variable documentation so that it shows the correct location of the
CMake argument.

Build: Fix Debug/RelWithDebInfo build with YASM

YASM requires a debug format to be specified with -g.  Currently the
only combination that I can make work at all is DWARF-2/ELF (YASM
doesn't support Mach-O debugging at all, and its support for CV8/MSVC
and MinGW/DWARF-2 appears to be broken), so debugging is only enabled
automatically for ELF at the moment.  For other formats, we don't
specify -g at all, which is how the old build system behaved.

Fixes #125, Closes #126

Build: Set install dirs in a more GNU-friendly way

This builds upon the existing GNUInstallDirs module in CMake but adds
the following features to that module:

- The ability to override the defaults for each install directory
  through a new set of variables (`CMAKE_INSTALL_DEFAULT_*DIR`).

  Before operating system vendors began shipping libjpeg-turbo, it was
  meant to be a run-time drop-in replacement for the system's
  distribution of libjpeg, so it has traditionally installed itself
  under /opt/libjpeg-turbo on Un*x systems by default.  On Windows, it
  has traditionally installed itself under %SystemDrive%\libjpeg-turbo*,
  which is not uncommon behavior for open source libraries (open source
  SDKs tend to install outside of the Program Files directory so as to
  avoid spaces in the directory name.)  At least in the case of Un*x,
  the install directory behavior is based somewhat on the Solaris
  standard, which requires all non-O/S packages to install their files
  under /opt/{package_name}.  I adopted that standard for VirtualGL and
  TurboVNC while working at Sun, because it allowed those packages to be
  located under the same directory on all platforms.  I adopted it for
  libjpeg-turbo because it ensured that our files would never conflict
  with the system's version of libjpeg.  Even though many Un*x
  distributions ship libjpeg-turbo these days, not all of them ship the
  TurboJPEG API library or the Java classes or even the latest version
  of the libjpeg API library, so there are still many cases in which it
  is desirable to install a separate version of libjpeg-turbo than the
  one installed by the system.  Furthermore, installing the files under
  /opt mimics the directory structure of our official binary packages,
  and it makes it very easy to uninstall libjpeg-turbo.

  For these reasons, our build system needs to be able to use
  non-GNU-compliant defaults for each install directory if
  `CMAKE_INSTALL_PREFIX` is set to the default value.

- For each directory variable, the module now detects changes to
  `CMAKE_INSTALL_PREFIX` and changes the directory variable accordingly,
  if the variable has not been changed by the user.

  This makes it easy to switch between our "official" directory
  structure and the GNU-compliant directory structure "on the fly"
  simply by changing `CMAKE_INSTALL_PREFIX`.  Also, this new mechanism
  eliminated the need for the crufty mechanism that previously did the
  same thing just for the library directory variable.

  How it should work:
  - If a dir variable is unset, then the module will set an internal
    property indicating that the dir variable was initialized to its
    default value.
  - If the dir variable ever diverges from its default value, then the
    internal property is cleared, and it cannot be set again without
    unsetting the dir variable.
  - If the install prefix changes, and if the internal property
    indicates that the dir variable is still set to its default value,
    and if the dir variable's value is not being manually changed at the
    same time that the install prefix is being changed, then the dir
    variable's value is automatically changed to the new default value
    for that variable (as determined by the new install prefix.)

- The directory variables are now always cached, regardless of whether
  they were set on the command line or not.  This ensures that they can
  easily be examined and modified after being set, regardless of how they
  were set.

  This was made possible by the introduction of the aforementioned
  `CMAKE_INSTALL_DEFAULT_*DIR` variables.

- Improved directory variable documentation (based on descriptions at
  https://www.gnu.org/prep/standards/html_node/Directory-Variables.html)

- The module now allows "<DATAROOTDIR>" to be used as a placeholder in
  relative directory variables.

  It is replaced "on the fly" with the actual path of
  `CMAKE_INSTALL_DATAROOTDIR`.

This should more closely mimic the behavior of the old autotools build
system while retaining our customizations to it, and it should retain
the behavior of the old CMake build system.

Closes #124

Build: Fix Win "installer" target Java dependency

The correct target name is now "turbojpeg-java".

Build: Formatting tweak

(It is our convention to use lowercase for CMake macro/function names)

Build: Clean up inline keyword detection

Strict C89-conformant compilers don't support the "inline" keyword, but
most of them support "__inline__", and that keyword can be used with the
always_inline atribute as well.  This commit also removes duplicate code
by using a foreach() loop to test the various keywords.

Fix build when CFLAGS contains -std=c89 (or -ansi)

This is a subtle point, but AC_C_INLINE defines "inline" to be either
"inline", "__inline__", or "__inline".  The subsequent test for
"inline __attribute__((always_inline))" uses this definition.  The
attribute is irrespective of the inline keyword, so whereas
"__inline__ __attribute__((always_inline))" works under C89,
"inline __attribute__((always_inline))" doesn't, and defining INLINE to
the latter causes the build to fail.  The easiest way around this is
simply to define "inline" ahead of "INLINE" in jconfigint.h,
which causes the inline keyword detected by AC_C_INLINE to modify the
INLINE macro if necessary.

Reorg AltiVec detection code

+ advertise that full AltiVec SIMD acceleration is now available on
OpenBSD.

The relevant compilers probably all support C99 or GNU's variation of
C90 that allows variables to be declared anywhere, but our policy is to
conform to the C90 standard, if for no other reason than that it
improves code readability.

Detect AltiVec support on OpenBSD

Packaging: Use correct name for SRPM spec file

Per convention, the file should be named {package name}.spec.

Fix sign mismatch comparison warnings

Fixes:
rdppm.c:257:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
    if (temp > maxval)
        ~~~~ ^ ~~~~~~
rdppm.c:284:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
    if (temp > maxval)
        ~~~~ ^ ~~~~~~
rdppm.c:289:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
    if (temp > maxval)
        ~~~~ ^ ~~~~~~
rdppm.c:294:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
    if (temp > maxval)

Build: Fix issues when building as a Git submodule

- Replace CMAKE_SOURCE_DIR with CMAKE_CURRENT_SOURCE_DIR
- Replace CMAKE_BINARY_DIR with CMAKE_CURRENT_BINARY_DIR
- Don't use "libjpeg-turbo" in any of the package system filenames
  (because CMAKE_PROJECT_NAME will not be the same if building LJT as
  a submodule.)

Closes #122

Build: Fix buglet in output of `make tjtest`

Build: Fix regression in AltiVec SIMD detection

Only the SIMD source files should be built with -maltivec.  Otherwise
the detection code will not be compiled in.

Fix md5cmp on AmigaOS 4 (PowerPC big-endian)

+ Document AmigaOS support in the change log.

Based on:
https://github.com/chris-y/libjpeg-turbo/commit/b4f3b757970cd9dd448af9d2713b6bcdd9929147

Closes #119

Travis: Use xcode7.3 image

The xcode7.2 image is verfallen, verlumpt, verblunget, verkackt

This also ensures that the build scripts are checked out from a
branch matching the libjpeg-turbo repository branch (not strictly
necessary when building from master, but it keeps the code in sync with
dev.)

Build: Use wrapper script for gas-preprocessor.pl

The previous hack (adding ${CMAKE_ASM_COMPILER} to CMAKE_ASM_FLAGS)
didn't work in all cases, because more recent versions of CMake place
the includes ahead of the flags (which meant that the real assembler
wasn't the first argument to gas-preprocessor.pl.)

Travis: Fix OS X build

+ migrate to new xcode7.3 image, since xcode7.2 is going away soon.

Build: Fix RPATH handling

CMAKE_INSTALL_RPATH has to be set before the targets are defined (oops.)

This also explicitly turns on MACOSX_RPATH for the shared libraries
(which is the default with newer versions of CMake but not with 2.8.x.)
The old autotools/libtool build system hard-coded the install name
directory of the OS X shared libraries to libdir, which meant that any
executable that linked against those libraries would also be hard-coded
to look for the libjpeg-turbo libraries in that directory.  @rpath makes
the OS X version of libjpeg-turbo behave like the Linux version, in the
sense that the executables under /opt/libjpeg-turbo/bin will
automatically pick up the libraries under /opt/libjpeg-turbo/lib* by
default, but other executables won't unless they are linked with -rpath.

Unified CMake-based build system

See #56 for discussion.

Fixes #21, Fixes #29, Fixes #37, Closes #56, Fixes #58, Closes #73
Obviates #82

See also:
https://sourceforge.net/p/libjpeg-turbo/feature-requests/5/
https://sourceforge.net/p/libjpeg-turbo/patches/5/

BUILDING.md: NASM 2.10+/YASM 1.2.0+ always needed

... for all x86[-64] builds, because we now have both 64-bit and 32-bit
AVX2 SIMD extensions.

Advertise the new AVX2 SIMD extensions

(our story so far ...)

Merge branch 'master' into dev

AppVeyor: Use built-in MSYS2 MinGW compilers

AppVeyor already has MinGW32 and MinGW64 flavors of GCC 5.3.0
installed under MSYS2, so there is no need to install our own builds of
MinGW.  MinGW-builds is no longer an active project, and we were getting
occasional timeouts while wgetting those files from SourceForge.
Furthermore, GCC 5.3.0 should produce faster code than GCC 4.8.1.

BUILDING.md: Clarifications and wordsmithing

Updated out-of-date information, wordsmithed and clarified many
sections, and generally cleaned up the build recipes (including a
complete overhaul of the iOS recipes.)

Windows build: Add an "uninstall" target

BUILDING.md/README.md: Increment libjpeg SO age

Documentation buglet.  This should have been changed in
6ed4d9d11085acd04dc7f2f899848693976dc010 to reflect the addition of
libjpeg API functions in libjpeg-turbo 1.5.

README.md: Don't use trailing spaces as line break

Makes it easier to maintain this file using editors that automatically
remove trailing spaces.

TJBench: Fix regression/-nowrite always enabled

Introduced by eb59b6e72d8098a1f7b8c7e0c710b32eb6f5dc45

BUILDING.md: Don't use trailing spaces as line break

Makes it easier to maintain this file using editors that automatically
remove trailing spaces.

CMake build system: Fix the "testclean" target

Regression caused by f9134384b728d8943f252b27464d83c4b7b2d159

This commit also makes the "testclean" target clean up the 4:1:1 test
images.  This was implemented in the autotools build system in
1f3635c4969f2319a01c9fe561958815b733227f but was left out of the CMake
build system due to an oversight.

Detect AltiVec support on AmigaOS 4

Merge branch 'master' into dev

Travis: Deploy to S3 rather than SourceForge

This has the following advantages:
-- It doesn't require checking a private SSH key into the repository.
(With SourceForge, an SSH key is the "keys to the kingdom".)
-- If the S3 key is compromised, it is very easy to revoke it and
generate a new one.
-- The S3 bucket is isolated, so even if it becomes compromised, then
the damage that one could do is limited.
-- It's much easier to manage files through S3's web interface than
through SourceForge.
-- The files are served via HTTPS.
-- Travis fully supports S3 as a deployment target, so this simplifies
.travis.yml somewhat.

Merge branch 'master' into dev

Travis: GPG sign Linux binaries/source tarballs

Since we're still deploying our Linux/macOS CI artifacts to a web server
(specifically SourceForge Project Web Services) that doesn't support
HTTPS, it's a good idea to sign them.  But since the private key has to
be checked into the repository, we use a different key for signing the
pre-releases (per project policy, the private signing keys for our
release binaries are never made available on any public server.)

Win: Use YASM if it is in the PATH and NASM isn't

Previously, simd/CMakeLists.txt was hard-coded to use NASM, and it was
necessary to override the NASM variable in order to use YASM.  This
commit changes the behavior such that NASM is still preferred, but YASM
will be used if it is in the PATH and NASM isn't available.  This brings
the actual behavior in line with the behavior described in BUILDING.md.

Based on
https://github.com/xpol/libjpeg-turbo/commit/b0799a1598782799d4876538eddca7ad8438d8a6

Closes #107

Merge branch 'master' into dev

Travis: Fix deployment issue (2nd attempt)

Merge branch 'master' into dev

Travis: Fix deployment issue

"Skipping a deployment with the script provider because this branch is
not permitted"

Fix AppVeyor build on non-master branches

buildljt will clone the Git repository into the temp. directory, even if
the repository is really a local sandbox, so we need to specify the
branch.

Travis: Use existing sandbox for official builds

This eliminates the need to specify the remote repository and branch,
and it prevents the code from being checked out twice.

Merge branch 'master' into dev

Add AppVeyor config for Windows pre-release builds

Travis CI: Fixes to support AVX2 code

-- Use trusty for SIMD builds.  Ubuntu 12.04 is still using NASM 2.09.x,
   which isn't new enough to support AVX2.
-- Add a special test for the SSE2 code path, since it is no longer the
   default.

Merge branch 'master' into dev

Travis: use correct repo/branch for off. builds

Pass the actual repository and branch that Travis is using into the
builtljt script, so the official builds it generates will come from
the same code base as the other tested builds.

Fix 'make dist'

Travis CI: Use correct key for this repository

Add Travis CI config for Un*x pre-release builds

Fix 32-bit non-SIMD FP regression tests

- Introduce a new FLOATTEST value ("387") on Un*x systems that will
  compare the floating point DCT/IDCT algorithms against the expected
  results from the C algorithms when built using 32-bit code and
  -mfpmath=387.
- Extend the Windows regression tests so that they work properly when
  building libjpeg-turbo with 32-bit code and without SIMD, using either
  Visual C++ (tested with 2008, 2010, 2015) or MinGW.

Fix broken build w/ Visual C++ < 2010

Regression introduced by dfefba77520ded5c5fd4864e76352a5f3eb23e74
(Windows doesn't always have stdint.h.)

Fix broken MIPS build

Regression introduced by 9055fb408dcb585ce9392d395e16630d51002152

Fixes #104

Fix UBSan warning in arithmetic decoder

Very similar to the ones that were fixed in the Huffman decoders in
8e9cef2e6f5156c4b055a04a8f979b7291fc6b7a.  These are innocuous.

Refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1304567.

Fix broken build with NDK platforms < android-21

Regression introduced by a09ba29a55b9a43d346421210d94370065eeaf53

Fixes #103

Bump version to 1.5.2 to prepare for new commits

README.md: Fix typo

Introduced in 17de51835735e319ada5ca139a64227423946a8a

Closes #102

Merge branch 'master' into dev

ARM64 NEON: Fix another ABI conformance issue

Based on
https://github.com/mayeut/libjpeg-turbo/commit/98a5a9dc899aa9265858a3cbe0a96289a31a1322
with wordsmithing by DRC.

In the AArch64 ABI, as in many others, it's forbidden to read/store data
below the stack pointer.  Some SIMD functions were doing just that
(stack pointer misuse) when trying to preserve callee-saved registers,
and this resulted in those registers being restored with incorrect
contents under certain circumstances.

This patch fixes that behavior, and callee-saved registers are now
stored above the stack pointer throughout the function call.  The patch
also removes register saving in places where it is unnecessary for this
ABI, or it makes use of unused scratch regiters instead of callee-saved
registers.

Fixes #97.  Closes #101.

Refer also to https://bugzilla.redhat.com/show_bug.cgi?id=1368569

Build: Remove ARMv6 support from 'make iosdmg'

The last iDevice to require ARMv6 was the iPhone 3G, which required iOS
4.2.1 or older.  Our binaries have always required iOS 4.3 or newer,
so I'm not sure if the ARMv6 fork of our binaries was ever useful to
begin with.  In any case, if it ever was useful, it no longer is.  Fat
binaries can still be generated with ARMv6 support by invoking
{build_directory}/pkgscripts/makemacpkg manually.

Fix out-of-bounds write in partial decomp. feature

Reported by Clang UBSan (refer to
https://bugzilla.mozilla.org/show_bug.cgi?id=1301252 for test image.)
This appears to be a legitimate bug introduced by
3ab68cf563f6edc2608c085f5c8b2d5d5c61157e.  Any component array, such
as first_MCU_col and last_MCU_col, should always be able to accommodate
MAX_COMPONENTS values.  The aforementioned test image had 8 components,
which was not enough to make the out-of-bounds write bust out of the
jpeg_decomp_master struct (and fortunately the memory after last_MCU_col
is an integer used as a boolean, so stomping on it will do nothing other
than change the decoder state.)  I crafted another special image that
has 10 components (the maximum allowable), but that was apparently not
enough to bust out of the allocated memory, either.  Thus, it is
posited that the security threat posed by this bug is either extremely
minimal or non-existent.

Silence additional UBSan warnings

NOTE: The jdhuff.c/jdphuff.c warnings should have already been silenced
by 8e9cef2e6f5156c4b055a04a8f979b7291fc6b7a, but apparently I need to
be REALLY clear that I'm trying to do pointer arithmetic rather than
dereference an array.  Grrr...

Refer to:
https://bugzilla.mozilla.org/show_bug.cgi?id=1301250
https://bugzilla.mozilla.org/show_bug.cgi?id=1301256

Fix unsigned int overflow in libjpeg memory mgr.

When attempting to decode a malformed JPEG image (refer to
https://bugzilla.mozilla.org/show_bug.cgi?id=1295044) with dimensions
61472 x 32800, the maximum_space variable within the
realize_virt_arrays() function will exceed the maximum value of a 32-bit
integer and will wrap around.  The memory manager subsequently fails
with an "Insufficient memory" error (case 4, in alloc_large()), so this
commit simply causes that error to be triggered earlier, before UBSan
has a chance to complain.

Note that this issue did not ever represent an exploitable security
threat, because the POSIX-based memory manager that we use doesn't ever
do anything meaningful with the value of maximum_space.
jpeg_mem_available() simply sets avail_mem = maximum_space, so the
subsequent behavior of the memory manager is the same regardless of
whether maximum_space is correct or not.  This commit simply removes a
UBSan warning in order to make it easier to detect actual security
issues.

TurboJPEG: Decomp. 4:2:2/4:4:0 JPEGs w/unusual SFs

Normally, 4:2:2 JPEGs have horizontal x vertical luminance,chrominance
sampling factors of 2x1,1x1, and 4:4:0 JPEGs have horizontal x vertical
luminance,chrominance sampling factors of 1x2,1x1.  However, it is
technically legal to create 4:2:2 JPEGs with sampling factors of
2x2,1x2 and 4:4:0 JPEGs with sampling factors of 2x2,2x1, since the
sums of the products of those sampling factors (2x2 + 1x2 + 1x2 and
2x2 + 2x1 + 2x1) are still <= 10.  The libjpeg API correctly decodes
such images, so the TurboJPEG API should as well.

Fixes #92

Silence pedantic GCC6 code formatting warnings

Apparently it's "misleading" to put two self-contained if statements
on a single line.  Who knew?

Use plain upsampling if merged isn't accelerated

Currently, this only affects ARM, since it is the only platform that
accelerates YCbCr-to-RGB conversion but not merged upsampling.  Even if
"plain" upsampling isn't accelerated, the combination of accelerated
color conversion + unaccelerated plain upsampling is still faster than
the unaccelerated merged upsampling algorithms.

Closes #81

Implement h1v2 fancy upsampling

This allows fancy upsampling to be used when decompressing 4:2:2 images
that have been losslessly rotated or transposed.

(docs and comments added by DRC)

Based on https://github.com/pornel/libjpeg-turbo/commit/f63aca945debde07e7c6476a1f667b71728c3d44

Closes #89

AVX2: Perform additional checks for O/S support

cpuid tells us whether the O/S uses extended state management via
XSAVE/XRSTOR, but we have to call xgetbv to verify that it is using
XSAVE/XRSTOR to manage the state of XMM/YMM registers.

Fix AArch64 ABI conformance issue in SIMD code

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 https://github.com/sebpop/libjpeg-turbo/commit/1fbae13021eb98f6fffdfaf8678fcdb00b0b04d9

Closes #91.  Refer also to android-ndk/ndk#110 and
https://llvm.org/bugs/show_bug.cgi?id=28393

Don't install libturbojpeg.pc if TJPEG disabled

AVX2: Verify O/S support for AVX2 before enabling

This fixes crashes that would occur when attempting to use
libjpeg-turbo's AVX2 extensions on older O/S's (such as Windows XP or
RHEL 5.)  Even if the CPU supports AVX2, the O/S has to also support
saving/restoring YMM registers when switching contexts.

Reformat jsimdcpu[-64].asm to improve readability

Merge branch 'master' into dev