[Bug target/58693] New: GCC aarch64 arm_neon.h inconsistent with Apple clang arm64 arm_neon.h

[Bug target/58693] New: GCC aarch64 arm_neon.h inconsistent with Apple clang arm64 arm_neon.h

[lennox at cs dot columbia.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58693

            Bug ID: 58693
           Summary: GCC aarch64 arm_neon.h inconsistent with Apple clang
                    arm64 arm_neon.h
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lennox at cs dot columbia.edu

Created attachment 30984
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30984&action=edit
Diff between functions in Apple Clang and GCC aarch64 arm_neon.h

Both GCC and Apple clang have extended the standard ARM arm_neon.h header file
to support new operations supported by ARMv8 chips running in aarch64 mode.

However, GCC and Apple seem to have extended these headers in inconsistent
ways. They should presumably be consistent.

I don't know what is supposed to be a canonical definition of this header.  I
can't find any aarch64 definition of arm_neon.h anywhere in the documentation
on arm.com.

It's not clear to what extent the inconsistencies between GCC and Apple are
different names for the same assembly instructions, and to what extent they are
defining different operations.  (There appears to be some of both.)

I've attached a list of the differences in the names of the intrinsic functions
between the two compilers (produced by scraping the output of
aarch64-unknown-linux-gnu-gcc -E -include arm_neon.h -x c /dev/null and
aarch64-unknown-linux-gnu-gcc -E -dM -include arm_neon.h -x c /dev/null, and
equivalently with xcrun --sdk iphoneos clang -arch arm64 on a Mac with Xcode
5.)

Note that some of these intrinsic functions are to support the ARMv8 crypto
extension, not aarch64 per se.

[Bug target/58693] GCC aarch64 arm_neon.h inconsistent with Apple clang arm64 arm_neon.h

[lennox at cs dot columbia.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58693

--- Comment #1 from Jonathan Lennox <lennox at cs dot columbia.edu> ---
Note: I have also filed the equivalent bug with Apple.

[Bug target/58693] GCC aarch64 arm_neon.h inconsistent with Apple clang arm64 arm_neon.h

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58693

jgreenhalgh at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jgreenhalgh at gcc dot gnu.org

--- Comment #2 from jgreenhalgh at gcc dot gnu.org ---
The canonical reference for the AArch64 arm_neon.h intrinsics is now available
from:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0073a/index.html

I'm tempted to mark this bug as invalid as differences from Clang are not an
issue on their own and many of the intrinsics identified in this PR are not in
the ARM Neon Intrinsics Reference specification. The problem is that GCC does
not yet conform to the linked specification (and I suspect, neither does
Clang). Alan Lawrence had a patch recently to remove some of the extra
intrinsics we were defining (
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02556.html ), and I've seen
several others go past adding some of the missing intrinsics, but we are not
there yet.

I'll leave the bug report open, as the consequence of this is potentially
confusing for users.

[Bug target/58693] GCC aarch64 arm_neon.h inconsistent with Apple clang arm64 arm_neon.h

[lennox at cs dot columbia.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58693

--- Comment #3 from Jonathan Lennox <lennox at cs dot columbia.edu> ---
As the original poster, I agree -- GCC Aarch64 should implement the intrinsics
in ACLE 2.0 (Neon and otherwise), and so should Clang.

At the time I filed the bug ACLE 2.0 hadn't been made public yet.

Marking this bug invalid is fine with me, so long as we have a separate bug to
implement the intrinsics according to the spec.  Some searching doesn't yet
reveal any such bug, though.