On big-endian machines, a test case looking for the methods _L1D and _E1D

From: Al Stone <ahs3@redhat.com>

in the same scope would fail (see tests/misc/badcode.asl:184).  The names
to be compared were being treated as 32-bit ints, and not strings.  Hence,
the characters were re-ordered incorrectly, mismatching the assumptions
made in the remainder of the function.
---
 source/compiler/aslanalyze.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: acpica-unix2-20161222/source/compiler/aslanalyze.c
===================================================================
--- acpica-unix2-20161222.orig/source/compiler/aslanalyze.c
+++ acpica-unix2-20161222/source/compiler/aslanalyze.c
@@ -461,7 +461,7 @@ ApCheckForGpeNameConflict (
 
     /* Need a null-terminated string version of NameSeg */
 
-    ACPI_MOVE_32_TO_32 (Name, &Op->Asl.NameSeg);
+    ACPI_MOVE_NAME (Name, &Op->Asl.NameSeg);
     Name[ACPI_NAME_SIZE] = 0;
 
     /*
@@ -488,7 +488,7 @@ ApCheckForGpeNameConflict (
      * We are now sure we have an _Lxx or _Exx.
      * Create the target name that would cause collision (Flip E/L)
      */
-    ACPI_MOVE_32_TO_32 (Target, Name);
+    ACPI_MOVE_NAME (Target, Name);
 
     /* Inject opposite letter ("L" versus "E") */