[libpng17] Completed AArch64 support. Previous change to recognize __ARM_NEON

didn't touch all the required preprocessor lines. This change removes
support for __ARM_NEON__ completely and makes this consistent.
This commit is contained in:
John Bowler 2015-06-04 21:55:35 -05:00 committed by Glenn Randers-Pehrson
parent 1a9eb510eb
commit e55c190818
3 changed files with 27 additions and 14 deletions

View File

@ -828,6 +828,9 @@ Version 1.7.0beta63 [June 5, 2015]
API in pngread.c but that is because of a long-standing libpng bug,
namely that the gamma corrected palette is no produced by
png_read_update_info (John Bowler).
Completed AArch64 support. The previous change to recognize __ARM_NEON
didn't touch all the required preprocessor lines. This change removes
support for __ARM_NEON__ completely and makes this consistent.
Send comments/corrections/commendations to png-mng-implement at lists.sf.net
(subscription required; visit

View File

@ -5123,6 +5123,14 @@ Version 1.7.0beta63 [June 5, 2015]
API in pngread.c but that is because of a long-standing libpng bug,
namely that the gamma corrected palette is no produced by
png_read_update_info (John Bowler).
Completed AArch64 support. The previous change to recognize __ARM_NEON
didn't touch all the required preprocessor lines. This change removes
support for __ARM_NEON__ completely and makes this consistent.
This change ensures that only compilers which are tracking ARM Ltd
specifications will turn the NEON code on, since the code is turned on
automatically for AArch64 this seems much safer than trying to track all teh
bugs in all the versions of GCC.
Send comments/corrections/commendations to png-mng-implement at lists.sf.net
(subscription required; visit

View File

@ -136,7 +136,7 @@
* NOTE: symbol prefixing does not pass $(CFLAGS) to the preprocessor, because
* this is not possible with certain compilers (Oracle SUN OS CC), as a result
* it is necessary to ensure that all extern functions that *might* be used
* regardless of $(CFLAGS) get declared in this file. The test on __ARM_NEON__
* regardless of $(CFLAGS) get declared in this file. The test on __ARM_NEON
* below is one example of this behavior because it is controlled by the
* presence or not of -mfpu=neon on the GCC command line, it is possible to do
* this in $(CC), e.g. "CC=gcc -mfpu=neon", but people who build libpng rarely
@ -144,10 +144,10 @@
*/
#ifndef PNG_ARM_NEON_OPT
/* ARM NEON optimizations are being controlled by the compiler settings,
* typically the target FPU. If the FPU has been set to NEON (-mfpu=neon
* with GCC) then the compiler will define __ARM_NEON__ and we can rely
* unconditionally on NEON instructions not crashing, otherwise we must
* disable use of NEON instructions.
* typically the target FPU. If the FPU supports NEON instructions then the
* compiler will define __ARM_NEON and we can rely unconditionally on NEON
* instructions not crashing, otherwise we must disable use of NEON
* instructions.
*
* NOTE: at present these optimizations depend on 'ALIGNED_MEMORY', so they
* can only be turned on automatically if that is supported too. If
@ -155,15 +155,16 @@
* to compile with an appropriate #error if ALIGNED_MEMORY has been turned
* off.
*
* Note that gcc-4.9 defines __ARM_NEON instead of the deprecated
* __ARM_NEON__, so we check both variants.
* Note that older versions of GCC defined __ARM_NEON__; this is no longer
* supported. Also 32-bit ARM versions of GCC required the NEON FPU mode to
* be turned on explicitly on the command line. If this is not done (on
* 32-bit ARM) NEON code will not be included.
*
* To disable ARM_NEON optimizations entirely, and skip compiling the
* associated assembler code, pass --enable-arm-neon=no to configure
* or put -DPNG_ARM_NEON_OPT=0 in CPPFLAGS.
*/
# if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \
defined(PNG_ALIGNED_MEMORY_SUPPORTED)
# if defined(__ARM_NEON) && defined(PNG_ALIGNED_MEMORY_SUPPORTED)
# define PNG_ARM_NEON_OPT 2
# else
# define PNG_ARM_NEON_OPT 0
@ -177,12 +178,12 @@
# define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_neon
/* By default the 'intrinsics' code in arm/filter_neon_intrinsics.c is used
* if possible - if __ARM_NEON__ is set and the compiler version is not known
* if possible - if __ARM_NEON is set and the compiler version is not known
* to be broken. This is controlled by PNG_ARM_NEON_IMPLEMENTATION which can
* be:
*
* 1 The intrinsics code (the default with __ARM_NEON__)
* 2 The hand coded assembler (the default without __ARM_NEON__)
* 1 The intrinsics code (the default with __ARM_NEON)
* 2 The hand coded assembler (the default without __ARM_NEON)
*
* It is possible to set PNG_ARM_NEON_IMPLEMENTATION in CPPFLAGS, however
* this is *NOT* supported and may cease to work even after a minor revision
@ -191,7 +192,7 @@
* libpng implementation list for incorporation in the next minor release.
*/
# ifndef PNG_ARM_NEON_IMPLEMENTATION
# ifdef __ARM_NEON__
# ifdef __ARM_NEON
# if defined(__clang__)
/* At present it is unknown by the libpng developers which versions
* of clang support the intrinsics, however some or perhaps all
@ -207,7 +208,8 @@
# endif /* no GNUC support */
# endif /* __GNUC__ */
# else /* !defined __ARM_NEON__ */
/* The 'intrinsics' code simply won't compile without this -mfpu=neon:
/* The 'intrinsics' code simply won't compile without compiler support
* and that support switches on __ARM_NEON, so use the assembler:
*/
# define PNG_ARM_NEON_IMPLEMENTATION 2
# endif /* __ARM_NEON__ */