Berkeley UPC compiler error upcc: error running '/bin/gmake --no-print-directory' to link application - upc

I am trying to compile a group of codes. Any idea why I am getting an error ? Thanks for your help.
upcc -c -O code9xc_sac.upc -I/global/software/sl-7.x86_64/modules/tools/proj.4/4.9.3/include
gcc -c -O2 code7fft.c -funroll-loops -ftree-vectorize
upcc -o xcorupc_sac code9xc_sac.o code7fft.o /global/software/sl-7.x86_64/modules/gcc/7.4.0/fftw/3.3.8-gcc/lib/libfftw3.a /bearbin-data3/home/anayak7/Programs/sac/lib/sacio.a /bearbin-data3/home/anayak7/Programs/sac/lib/libsac.a /usr/local/software/sl-7.x86_64/modules/metis/5.1.0/lib/libmetis.a -I/global/software/sl-7.x86_64/modules/tools/proj.4/4.9.3/include -L/global/software/sl-7.x86_64/modules/tools/proj.4/4.9.3/lib -lproj -lm
upcc: error running '/bin/gmake --no-print-directory' to link application:
/usr/bin/ld: cannot find -libverbs
collect2: error: ld returned 1 exit status
gmake[1]: *** [link] Error 1
make: *** [all] Error 255
EDIT: I have checked the group of codes on a different computer. The compilation is successful and the codes work. But in that computer I have compiled all the dependent libraries myself from scratch. However, on this computer I am using libraries from modules in the software farm. This is not working.
This is the output from upcc --version
-bash-4.2$ upcc --version
This is upcc (the Berkeley Unified Parallel C compiler), v. 2019.4.4
(getting remote translator settings...)
----------------------+---------------------------------------------------------
UPC Runtime | v. 2019.4.4, built on Nov 26 2019 at 10:44:35
----------------------+---------------------------------------------------------
UPC-to-C translator | v. 2.28.0, built on Jul 19 2018 at 20:29:47
| host aphid linux-x86_64/64
| gcc v4.2.4 (Ubuntu 4.2.4-1ubuntu4)
----------------------+---------------------------------------------------------
Translator location | http://upc-translator.lbl.gov/upcc-2019.4.0.cgi
----------------------+---------------------------------------------------------
networks supported | smp udp mpi ibv
----------------------+---------------------------------------------------------
default network | ibv
----------------------+---------------------------------------------------------
pthreads support | available (if used, default is 2 pthreads per process)
----------------------+---------------------------------------------------------
Configured with | '--with-translator=http://upc-translator.lbl.gov/upcc-2
| 019.4.0.cgi' '--enable-segment-large'
| '--with-sptr-packed-bits=20,9,35'
| '--disable-aligned-segments'
| '--prefix=/global/software/sl-7.x86_64/modules/gcc/7.4.
| 0/berkeley_upc/2019.4.4-gcc/opt'
| '--with-multiconf-magic=opt'
----------------------+---------------------------------------------------------
Configure features | trans_bupc,pragma_upc_code,driver_upcc,runtime_upcr,
| gasnet,upc_collective,upc_io,upc_memcpy_async,
| upc_memcpy_vis,upc_ptradd,upc_thread_distance,upc_tick,
| upc_sem,upc_dump_shared,upc_trace_printf,
| upc_trace_mask,upc_local_to_shared,upc_all_free,
| upc_atomics,pupc,upc_types,upc_castable,upc_nb,nodebug,
| notrace,nostats,nodebugmalloc,nogasp,nothrille,
| segment_large,os_linux,cpu_x86_64,cpu_64,cc_gnu,
| packedsptr,upc_io_64
----------------------+---------------------------------------------------------
Configure id | n0009.scs00 Tue Nov 26 10:34:27 PST 2019 sjames
----------------------+---------------------------------------------------------
Binary interface | 64-bit x86_64-unknown-linux-gnu
----------------------+---------------------------------------------------------
Runtime interface # | Runtime supports 3.0 -> 3.13: Translator uses 3.6
----------------------+---------------------------------------------------------
| --- BACKEND SETTINGS (for ibv network) ---
----------------------+---------------------------------------------------------
C compiler | /global/software/sl-7.x86_64/modules/langs/gcc/6.3.0/bi
| n/gcc
| GNU/6.3.0/6.3.0
| gcc (GCC) 6.3.0 Copyright (C) 2016 Free Software
| Foundation, Inc.
----------------------+---------------------------------------------------------
C compiler flags | -O3 --param max-inline-insns-single=35000 --param
| inline-unit-growth=10000 --param
| large-function-growth=200000 -Wno-unused
| -Wunused-result -Wno-unused-parameter -Wno-address
----------------------+---------------------------------------------------------
linker | /global/software/sl-7.x86_64/modules/gcc/6.3.0/openmpi/
| 3.0.1-gcc/bin/mpicc
| GNU/7.4.0/7.4.0
| gcc (GCC) 7.4.0 Copyright (C) 2017 Free Software
| Foundation, Inc.
----------------------+---------------------------------------------------------
linker flags | -D_GNU_SOURCE=1 -O3 --param
| max-inline-insns-single=35000 --param
| inline-unit-growth=10000 --param
| large-function-growth=200000 -Wno-unused
| -Wunused-result -Wno-unused-parameter -Wno-address
| -L/usr/local/software/sl-7.x86_64/modules/berkeley_upc/
| 2019.4.4-gcc-7.4.0/opt/lib -lupcr-ibv-seq -lumalloc
| -L/usr/local/software/sl-7.x86_64/modules/berkeley_upc/
| 2019.4.4-gcc-7.4.0/opt/lib -lgasnet-ibv-seq -libverbs
| -lpthread -lrt
| -L/global/software/sl-7.x86_64/modules/langs/gcc/6.3.0/
| lib/gcc/x86_64-pc-linux-gnu/6.3.0 -lgcc -lm
----------------------+---------------------------------------------------------

This looks like a system configuration issue - it appears you have Berkeley UPC installed for an InfiniBand network that is either improperly installed or possibly absent on your system. This may be a result of installation via a package manager, instead of building from source which is the only recommended/supported means for installing Berkeley UPC.
If all you want is to run jobs on the local node, I'd recommend compiling with upcc -network=smp to enable the smp loopback backend, which should not depend on the InfiniBand libraries. If you are trying to run jobs on a multi-node network, your best bet is to rebuild from source, following the install instructions.
NOTE: StackOverflow's interface is cumbersome for tracking down these types of issues. If these simple suggestions don't solve your problem, I'd highly recommend submitting a bug report at the Berkeley UPC issue tracker, and we can help you track it down further from there. Failing that, email to the "upc-users AT lbl.gov" list would be a better forum for diagnosing.

Related

My compiled GNU GCC 9 in Solaris 10 SPARC is not working

I have successfully compiled GNU GCC-9.1.0 successfully into Solaris 10 SPARC edition OS on my Sun/Oracle SPARC server.
I have had to however copy the static library files of libgmp.so, libmfr.so and libmpc.so into the following directories created during the 'gmake' process
gcc-9.1.0/host-sparc-sun-solaris2.10/gcc
gcc-9.1.0/host-sparc-sun-solaris2.10/prev-gcc
I now have a problem when I try to configure using the './configure' command any tarball archive containing C code source files. When I type in './configure' I get an error message saying 'C Compiler does not work, see config.log file for details' . I have uploaded the relevant config.log file generated into the following URL. It mentions that a static library file named 'libmpc.so.3 is missing, however the library file is present within /usr/local/lib directory. How do I resolve this situation. I shall appreciate any help given to me
configure:2912: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sparc-sun-solaris2.10/9.1.0/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with: ./configure --enable-obsolete --with-gmp-lib=/usr/local/lib --with-mpfr-lib=/usr/local/lib --with-mpc-lib=/usr/local/lib
...[snip]...
configure:2975: gcc conftest.c >&5
ld.so.1: cc1: fatal: libmpc.so.3: open failed: No such file or directory
gcc: fatal error: Killed signal terminated program cc1
compilation terminated.
configure:2978: $? = 1
configure:3016: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3023: error: C compiler cannot create executables
(full config.log is at http://tab140.freewebspace.com/config-gcc9.txt)
cc1 (the compiler proper executable) depends on the dynamic libmpc.so.3 library.
See
ldd `gcc --print-file-name cc1`
It should show you that mpc and other libraries are not found. This is because /usr/local/lib is not on your runtime shared library path, and you are responsible for making sure it is.
One option is to temporarily put it there: try
LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH ldd `gcc --print-file-name cc1`
If "not found" messages are gone in the second output, you can prefix all your commands involving invocations of gcc (such as ./configure, gmake, etc.) with LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH. Alternatively, you can export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH, but that still will work only for the current shell session. To make the changes permanent you can add the export command to your profile (e.g. ~/.bashrc file for bash, I don't know what shell you are using).
GCC has an installation manual that documents the --with-mpc-lib option among others:
'--with-gmp=PATHNAME'
'--with-gmp-include=PATHNAME'
'--with-gmp-lib=PATHNAME'
'--with-mpfr=PATHNAME'
'--with-mpfr-include=PATHNAME'
'--with-mpfr-lib=PATHNAME'
'--with-mpc=PATHNAME'
'--with-mpc-include=PATHNAME'
'--with-mpc-lib=PATHNAME'
If you want to build GCC but do not have the GMP library, the MPFR
library and/or the MPC library installed in a standard location and
do not have their sources present in the GCC source tree then you
can explicitly specify the directory where they are installed
('--with-gmp=GMPINSTALLDIR', '--with-mpfr=MPFRINSTALLDIR',
'--with-mpc=MPCINSTALLDIR'). The '--with-gmp=GMPINSTALLDIR' option
is shorthand for '--with-gmp-lib=GMPINSTALLDIR/lib' and
'--with-gmp-include=GMPINSTALLDIR/include'. Likewise the
'--with-mpfr=MPFRINSTALLDIR' option is shorthand for
'--with-mpfr-lib=MPFRINSTALLDIR/lib' and
'--with-mpfr-include=MPFRINSTALLDIR/include', also the
'--with-mpc=MPCINSTALLDIR' option is shorthand for
'--with-mpc-lib=MPCINSTALLDIR/lib' and
'--with-mpc-include=MPCINSTALLDIR/include'. If these shorthand
assumptions are not correct, you can use the explicit include and
lib options directly. You might also need to ensure the shared
libraries can be found by the dynamic linker when building and
using GCC, for example by setting the runtime shared library path
variable ('LD_LIBRARY_PATH' on GNU/Linux and Solaris systems).

GCC 8 conformance test failure when cross-compiling on macOS Mojave to target PowerPC

I'm trying to get a cross-compiler for my Intel MacBook Pro running macOS Mojave to compile for PowerPC G5 Macs. I've tried to follow a modified version of the steps from here but my configure command fails with this error message:
Assertion failed: (*offset_ptr == end_prologue_offset), function ParsePrologue, file /SourceCache/dwarf_utilities/dwarf_utilities-121.1/source/DWARFDebugLine.cpp, line 619.
collect2: fatal error: dsymutil terminated with signal 6 [Abort trap: 6]
compilation terminated.
*** The command 'gcc-8 -o conftest -g -O2 conftest.c' failed.
*** You must set the environment variable CC to a working compiler.
My configure command was:
CC=gcc-8 CXX=g++-8 ../gcc-8.3.0/configure \
--prefix=/opt/gcc/ppc/8 --disable-nls --disable-multilib --enable-languages=c,c++,objc,obj-c++,lto --with-dwarf2 \
--target=powerpc64-apple-darwin10.8.0 --with-sysroot=/Developer/SDKs/MacOSX10.5.sdk \
CFLAGS_FOR_TARGET="-isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -g -O2" \
LDFLAGS_FOR_TARGET="-isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5" \
CXXFLAGS_FOR_TARGET="-isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -g -O2"
My config log (available here) states this after the error message:
configure:5025: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h. */
|
| #if (__GNUC__ < 4) || (__GNUC__ == 4 && __GNUC_MINOR__ < 5)
| #error -static-libstdc++ not implemented
| #endif
| int main() {}
I am using the GCC 8.3.0 source code and the script-downloaded mpfr (3.1.4), gmp (6.1.0), mpc (1.0.3), and isl (0.18), as well as GCC and G++ version 8.3.0_2 installed using Homebrew as the actual compilers (accessible through gcc-8 and g++-8, respectively). I also have the Mac OS X 10.5 SDK installed via XcodeLegacy and an extracted dsymutil from Xcode 6.4.
The 32-bit PowerPC configuration command given in the original article also gives the same failure output, as do any other commands when a target is specified (e.g. powerpc64-unknown-linux-gnu failed, as did x86_64-unknown-linux-gnu and x86_64-apple-darwin18.5.0). This exact command (without target specification) completed successfully:
CC=gcc-8 CXX=g++-8 ../gcc-8.3.0/configure \
--prefix=/opt/gcc/x86/8 --disable-nls --disable-multilib --enable-languages=c,c++,objc,obj-c++,lto --with-dwarf2
I also noticed that in the output of the configuration of the command without a specified target, it stated that g++ accepted -static-libstdc++ -static-libgcc while in the cross-compiler configuration command outputs it stated that it didn't. I looked in the configure script to see what it actually did there, and it tries to compile and then link the sample C++ code, which ends up failing. Thus, the problem seems to be to either be a lack of the static libraries installed or an issue with the linker or compiler.
EDIT: I also have Xcode 10.2.1 and Command Line Tools for Xcode 10.2.1 (10E1001) installed.
EDIT 2: I tried configuring a Linux x86-64 build with the command:
CC=gcc-8 CXX=g++-8 ../gcc-8.3.0/configure \
--prefix=/opt/gcc/x86-64/8 --disable-nls --disable-multilib --enable-languages=c,c++,objc,obj-c++,lto --with-dwarf2 \
--target=x86_64-unknown-linux-gnu
without first adding the old version of dsymutil to my path (which I didn't remove when I tried the command the first time), which did successfully create a configuration file (note that macOS also comes with a newer version of dysmutil that doesn't support PowerPC devices anymore, and that the older version's location was specifically added to the front of the PATH so that it was found first).
Additionally, the output stated that g++ did accept -static-libstdc++ -static-libgcc as well. As I'm using the same compiler, I would think that this would suggest that the issue lies in the Mac linker or static libraries. However, from what I understand of dysmutil and the console logs, it isn't the cause of the failure but fails as a result of it, so I don't know the significance of this. I also tried invoking the failed command itself directly with the old version of dysmutil in my path and without it (with no other changes), and it gives the same error message (assertion failed, etc.) with it and no error message without it.
EDIT 3: So I did some searching, and apparently static-libstdc++ and static-libgcc are part of GCC and require GNU binutils to be built (which I have). I was using ld as defined in the article (which basically just calls the Apple system ld if targeting PowerPC) as GNU binutils' ld does not support Darwin. Could this be the source of the issue?

c++11 std::unique_ptr error cmake 3.11.3 bootstrap

I am trying to bootstrap cmake 3.11.3 on Ubuntu 16.04.4 LTS xenial.
I have upgrade my gnu g++ compiler as follows:
> $ g++ --version
g++ (Ubuntu 8.1.0-5ubuntu1~16.04) 8.1.0 Copyright (C) 2018 Free
Software Foundation, Inc. This is free software; see the source for
copying conditions. There is NO warranty; not even for MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.
And manually re-pointed the symbolic links:
$ ll /usr/bin/*g++*
lrwxrwxrwx 1 root root 5 Jun 8 16:57 /usr/bin/g++ -> g++-8*
-rwxr-xr-x 1 root root 919832 Apr 24 15:02 /usr/bin/g++-5*
lrwxrwxrwx 1 root root 22 Jun 6 04:26 /usr/bin/g++-8 -> x86_64-linux-gnu-g++-8*
lrwxrwxrwx 1 root root 22 Jun 8 16:58 /usr/bin/x86_64-linux-gnu-g++ -> x86_64-linux-gnu-g++-8*
lrwxrwxrwx 1 root root 5 Apr 24 15:02 /usr/bin/x86_64-linux-gnu-g++-5 -> g++-5*
-rwxr-xr-x 1 root root 1071984 Jun 6 04:26 /usr/bin/x86_64-linux-gnu-g++-8*
However, I get the following error in the configuration of cmake:
$ sudo ./bootstrap
---------------------------------------------
CMake 3.11.3, Copyright 2000-2018 Kitware, Inc. and Contributors
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++
Makefile processor on this system is: make
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has stl wstring
g++ has <ext/stdio_filebuf.h>
---------------------------------------------
make: Warning: File 'Makefile' has modification time 2.3 s in the future
make: 'cmake' is up to date.
make: warning: Clock skew detected. Your build may be incomplete.
loading initial cache file /mnt/ganymede/user/gpeytavi/srv_admin/software/cmake-3.11.3/Bootstrap.cmk/InitialCacheFlags.cmake
CMake Error at CMakeLists.txt:92 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).
-- Configuring incomplete, errors occurred!
See also "/mnt/ganymede/user/gpeytavi/srv_admin/software/cmake-3.11.3/CMakeFiles/CMakeOutput.log".
See also "/mnt/ganymede/user/gpeytavi/srv_admin/software/cmake-3.11.3/CMakeFiles/CMakeError.log".
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------
Any idea why I get a c++11 std::unique_ptr non-compliant error?
In my case, the issue is because of the folder where I have CMake source code is in a mounted directory (in fact my entire rootfs is mounted over NFS)
So, I looked in 'mount' command output and selected '/run/user/1000' location as a local location as this is mounted using tmpfs and moved my CMake source code to this location.
with this, ./bootstrap && make && sudo make install executed successfully.
Actually the ./bootstrap script does try the different C++ standard flags with the compiler. So it should detect its capabilities automatically.
Please make sure you don't have any CXXFLAGS environment variable set and try from scratch again (the messages/warnings you get indicate several tries/errors in the same directory).
Output when Successful
As a reference on my Ubuntu calling CMake's ./bootstrap looks like this:
---------------------------------------------
CMake 3.11.20180423, Copyright 2000-2018 Kitware, Inc. and Contributors
Warning: This is an in-source build
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++ -std=gnu++1y
Makefile processor on this system is: make
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has stl wstring
g++ has <ext/stdio_filebuf.h>
---------------------------------------------
Debugging
For debugging your problem you also could:
Call ./bootstrap --verbose
Look into Bootstrap.cmk/cmake_bootstrap.log
Known Problem
I only once had a problem with bootstrap using clang compilers where I needed to do the following call:
export CXXFLAGS=-Xclang -std=c++1z -Xclang -stdlib=libc++
Alternative
If you just want to install the latest version see How to specify where CMake is installed in Ubuntu?
I was able to resolve the issue by ensuring that both the build machine and the NFS file server were synchronized by running ntpd on both.
For me it was clock skew. I use the below command :
date -s "2021-11-30 15:08:21"
to set the time to now for the server. Then it work, thanks...

Scan service and "This platform is not supported by Coverity"

I'm trying to submit a scan under OS X. The procedure I am following works great under 32-bit and 64-bit Linux, and a similar procedure works great under Winows with nmake. On OS X cov-build is failing with:
$ CXXFLAGS="-DNDEBUG -g2 -O3" cov-build --dir cov-int make -j 2
Coverity Build Capture (64-bit) version 8.5.0.3 on Darwin 12.6.0 x86_64
Internal version numbers: db70178643 p-kent-push-26368.949
Platform info:
Sysname = Darwin
Release = 12.6.0
Machine = x86_64
[ERROR] This platform is not supported by Coverity.
[ERROR] See documentation for the list of supported platforms.
A different OS X machine produces the same error:
$ CXXFLAGS="-DNDEBUG -g2 -O3" cov-build --dir cov-int make -j 2
Coverity Build Capture (64-bit) version 8.5.0.3 on Darwin 13.4.0 x86_64
Internal version numbers: db70178643 p-kent-push-26368.949
Platform info:
Sysname = Darwin
Release = 13.4.0
Machine = x86_64
[ERROR] This platform is not supported by Coverity.
[ERROR] See documentation for the list of supported platforms.
I'm having trouble locating the documentation:
$ cov-build --help
Coverity Build Capture (64-bit) version 8.5.0.3 on Darwin 12.6.0 x86_64
Internal version numbers: db70178643 p-kent-push-26368.949
No help found for 'cov-build'
Coverity Data Sheet states OS X is supported, and a press release states OS X 10.8 is supported.
AIX
FreeBSD
HP-UX
Linux
Mac OS X
NetBSD
Solaris
Windows
Why am I receiving [ERROR] This platform is not supported by Coverity, and how do I fix it?
The issue is that Mac OSX 10.8 isn't supported in the Coverity release you're using. It's somewhat common for Apple to break compatibility with Coverity with OS releases, unfortunately.
You can export COVERITY_UNSUPPORTED=1. This will bypass the platform support check, however there's no guarantee things will work as expected. You do have reasonably good odds of success.
This builds on Flash Sheridan and Caleb's suggestions. The problem was less with the platform and more with the compiler. Xcode 5.0 and 5.1 produced the scan build failure:
CXXFLAGS="-DNDEBUG -g2 -O3" cov-build --dir cov-int make -j 2
...
cat cov-int/build-log.txt
...
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../
lib/clang/5.0/include/stddef.h", line 29: error #109:
expression preceding parentheses of apparent call must have
(pointer-to-) function type
#if !defined(_PTRDIFF_T) || __has_feature(modules)
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../
lib/clang/5.0/include/stddef.h", line 31: error #59:
function call is not allowed in a constant expression
#if !__has_feature(modules)
...
The second work-around depends on Flash Sheridan and Caleb's workaround. It adds "use a different compiler". Below, we use MacPorts Clang 3.7 to perform a scan build.
$ CXX=/opt/local/bin/clang++-mp-3.7 COVERITY_UNSUPPORTED=1 CXXFLAGS="-DNDEBUG -g3 -O2" cov-build --dir cov-int make -j 8
Coverity Build Capture (64-bit) version 8.5.0.3 on Darwin 12.6.0 x86_64
Internal version numbers: db70178643 p-kent-push-26368.949
/opt/local/bin/clang++-mp-3.7 -DNDEBUG -g3 -O2 -fPIC -march=native -pipe -c cryptlib.cpp
/opt/local/bin/clang++-mp-3.7 -DNDEBUG -g3 -O2 -fPIC -march=native -pipe -c cpu.cpp
...
Emitted 134 C/C++ compilation units (100%) successfully
134 C/C++ compilation units (100%) are ready for analysis
The cov-build utility completed successfully.
For anyone interested, we are a Free and Open Source Software project, and we take advantage of the Coverity Scan Service at no charge. However, the documentation is kind of light.
If you want prescriptive instructions for performing Scan Builds for Unix, Linux, OS X and Windows, then see Crypto++ wiki | Coverity Scan.

Detect ARM NEON availability in the preprocessor?

According to the ARM ARM, __ARM_NEON__ is defined when Neon SIMD instructions are available. I'm having trouble getting GCC to provide it.
Neon available on this BananaPi Pro dev board running Debian 8.2:
$ cat /proc/cpuinfo | grep neon
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
I'm using GCC 4.9:
$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Try GCC and -march=native:
$ g++ -march=native -dM -E - </dev/null | grep -i neon
#define __ARM_NEON_FP 4
OK, try what Google uses for Android when building for Neon:
$ g++ -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -dM -E - </dev/null | grep -i neon
#define __ARM_NEON_FP 4
Maybe a ARMv7-a with a hard float:
$ g++ -march=armv7-a -mfloat-abi=hard -dM -E - </dev/null | grep -i neon
#define __ARM_NEON_FP 4
My questions are:
why am I not seeing __ARM_NEON__?
how do I detect Neon availability in the preprocessor?
And maybe:
what GCC switches should I use to enable Neon SIMD instructions?
Related, on a LeMaker HiKey, which is AARCH64/ARM64 running Linaro with GCC 4.9.2, here's the output from the preprocessor:
$ cpp -dM </dev/null | grep -i neon
#define __ARM_NEON 1
According to ARM, this board does have Advanced SIMD instructions even though:
$ cat /proc/cpuinfo
Processor : AArch64 Processor rev 3 (aarch64)
...
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
There are a number of questions hidden in here, I'll try to extract them in turn...
According to the ARM ARM, __ARM_NEON__ is defined when Neon SIMD instructions are available. I'm having trouble getting GCC to provide it.
That is compiler documentation for [an old version of] the ARM Compiler rather than the ARM Architceture Reference Manual. A better macro to check for the presence of the Advanced SIMD instructions would be __ARM_NEON, which is defined in the ARM C Language Extensions.
Try GCC and -march=native:
As you may have found. GCC for the ARM target separates out -march (For the architecture revision for which GCC should generate code), -mfpu (For the floating point/Advanced SIMD unit available) and -mfloat-abi (For how floating point arguments should be passed, and for the presence or absence of a floating point unit). Finally there is -mtune (Which asks GCC to try to optimise for a particular processor) and -mcpu (which acts as a combination of -mtune and -march).
By asking for -march=native You're asking GCC to generate code appropriate for the detected architecture of the processor on which you are running. This has no impact on the -mfpu setting, and so does not necessarily enable Advanced SIMD instruction generation.
Note that the above only applies to a compiler targeting AArch32. The AArch64 GCC does not support -mfpu and will detect presence of Advanced SIMD support through -march=native.
OK, try what Google uses for Android when building for Neon:
$ g++ -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -dM -E
These build flags are not sufficient to enable support for Advanced SIMD instructions, your notes may be incomplete. Of the -mfpu flags supported by GCC 4.9.2 I'd expect any of:
neon, neon-fp16, neon-vfpv4, neon-fp-armv8, crypto-neon-fp-armv8
To give you what you want.
According to ARM, this board does have Advanced SIMD instructions even though:
Looks like you're running on an AArch64 kernel, which exposes support for Advanced SIMD through the asimd feature - as in your example output.

Resources