On Wed, Jul 20, 2016 at 5:33 PM, Jim Wilson <[email protected]> wrote: > On Wed, Jul 20, 2016 at 2:14 PM, Jeffrey Walton <[email protected]> wrote: >> I'm having trouble with ARMv8/Aarch64. One is an early Mustang server > > ARMv8 implies 32-bit code (aarch32). Aaarch64 implies 64-bit code. > These are two different compilers, with two different sets of command > line options.
Thanks Jim. According to ARM, ARMv8 is 64-bit (http://www.arm.com/products/processors/armv8-architecture.php). Maybe I'm parsing the page incorrectly? (Note that I'm aware of Aarch32 execution environments on Aarch64. I'm not trying for that test case at the moment). >> $ g++ -DDEBUG -g3 -O0 -mfpu=neon-fp-armv8 -fPIC -pipe -c cryptlib.cpp >> g++: error: unrecognized command line option ‘-mfpu=neon-fp-armv8’ >> GNUmakefile:753: recipe for target 'cryptlib.o' failed > > -mfpu=neon-fp-armv8 is an arm (32-bit) compiler option. The aarch64 > (64-bit) compiler will not accept it. > > Because FP and Neon support is optional in the 32-bit arm > architecture, there are compiler options to enable fp and/or neon > support. Usually FP support is enabled by default for a linux distro, > but the neon support usually is not, and you can enable neon by using > this -mcpu=neon-fp-armv8 option if running 32-bit code on an ARMv8 > architecture part. OK, thanks. So is neon-fp-armv8 an Aarch32 execution environment option? > Meanwhile, the aarch64 spec requires FP and ASIMD instruction support > in the linux ABI, so there are no options to enable them, they are on > by default. Yeah, I was clear on asimd being ARM-64's equivalent to NEON and it was enabled by default. > If you really want to disable them, you can do so by > using a -march= option, e.g. -march=aarch64+fp+simd enables them, and > -march=aarch64+nofp+nosimd disables them. However, if you disable fp > support, Oh, NO. We want to test under them. Sorry about the confusion. > you will break the ABI, and your code may not compile or run, > so don't do that unless perhaps you have an embedded target, and have > your own OS build and your own ABI. or no code that uses FP You can > also enable/.disable crc (crypto) support this way, but a better way > is to use a -mcpu= option, and let gcc figure out if the target has > crc instructions. > > See the aarch64 compiler docs here > https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options So it looks like the course of action is to simply remove it from http://github.com/weidai11/cryptopp/blob/master/cryptest.sh#L874 . (It was added recently because of the ML recommendation). These ARM options are awful. I spent the better part of a day trying to untangle the option combinations to ensure we are getting good test coverage in a test script. I'd give my left arm device for a compiler that provides -march=native or -mfpu=native and gets it right. Jeff _______________________________________________ linaro-toolchain mailing list [email protected] https://lists.linaro.org/mailman/listinfo/linaro-toolchain
