[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.

ANNOUNCE

@@ -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

CHANGES

@@ -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

pngpriv.h

@@ -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
+    * typically the target FPU.  If the FPU supports NEON instructions then the
-    * with GCC) then the compiler will define __ARM_NEON__ and we can rely
+    * compiler will define __ARM_NEON and we can rely unconditionally on NEON
-    * unconditionally on NEON instructions not crashing, otherwise we must
+    * instructions not crashing, otherwise we must disable use of NEON
-    * disable use of NEON instructions.
+    * 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
+    * Note that older versions of GCC defined __ARM_NEON__; this is no longer
-    * __ARM_NEON__, so we check both variants.
+    * 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)) && \
+#  if defined(__ARM_NEON) && defined(PNG_ALIGNED_MEMORY_SUPPORTED)
-   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__)
+    *    1  The intrinsics code (the default with __ARM_NEON)
-    *    2  The hand coded assembler (the default without __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__ */