I'm trying to compile C code on a Jetson Nano and I get this error during compiling. I tried removing any occurrence of 'm -64' but it seems like its added automatically. This is the cmd where it fails: /usr/bin/gcc-7 -Wall -Wextra -Wconversion -pedantic -Wshadow -m64 -Wfatal-errors -O0 -g -o CMakeFiles/dir/testCCompiler.c.o -c /home/user/dir/CMakeFiles/CMakeTmp/testCCompiler.c
uname -a: Linux jetson-nano 4.9.140-tegra aarch64 aarch64 aarch64 GNU/Linux
gcc-7 -v: Using built-in specs.
COLLECT_GCC=gcc-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/7/lto-wrapper
Target: aarch64-linux-gnu
gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)
CMAKE_C_COMPILER = gcc-7
CMAKE_CXX_COMPILER = g++-7
CXX_COMPILE_FLAGS = "-Wall -Werror -Wextra -Wnon-virtual-dtor -Wconversion -Wold-style-cast -pedantic -Wshadow"
C_COMPILE_FLAGS = "-Wall -Wextra -Wconversion -pedantic -Wshadow"
gcc-7: error: unrecognized command line option ‘-m64’
error: unrecognized command line option ‘-m64’
I believe you are looking for -march=armv8-a (and friends), and not -m64. The GCC arm64 options are available at 3.18.1 AArch64 Options in the manual.
Aarch64 includes ASIMD in the base specification, so there are no extra gyrations needed for it. ASIMD is "Advanced SIMD instructions", and it is what ARM calls NEON on the Aarch32 and Aarch64 architectures.
If you want to enable extensions, like CRC or Crypto, then the option would look like -march=armv8.1-a+crc or -march=armv8.1-a+crypto or -march=armv8.1-a+crc+crypto.
The equivalent x86 options would be the following. Obviously, the ARM port of GCC does not use the same model as x86. It is confusing for new users (or it was confusing for me).
-march=armv8-a → -msse2
-march=armv8.1-a+crc → -msse2 -msse4.1
-march=armv8.1-a+crypto → -msse2 -mpclmul -maes
-march=armv8.1-a+crc+crypto → -msse2 -msse4.1 -mpclmul -maes
ARM instruction set includes SHA in crypto, so the x86 options should probably include -msha. The problem is, x86 SHA did not arrive until about 8 years after carryless multiplies and AES.
Also, GCC ARM compilers usually don't understand -march=native. On older GCC compilers, the compiler will just crash. On mid-ranged GCC it is simply ignored. I believe the latest GCC compilers honor it.
This error often happens when cross-compiling with Rust/Cargo, because Cargo isn't smart enough to find cross-build tools by itself.
You need to set appropriate env vars. In the example replace x86_64_unknown_linux_gnu with your target, and paths to your cross-build paths (the example is for Debian). Watch out the env vars are case-sensitive and inconsistently named!
# for the cc crate
export HOST_CC=gcc
export CC_x86_64_unknown_linux_gnu=/usr/bin/x86_64-linux-gnu-gcc
# for Cargo
export CARGO_TARGET_X86_64-UNKNOWN-LINUX-GNU_LINKER=/usr/bin/x86_64-linux-gnu-gcc
Related
I'd like to ensure that a large set projects are build with the -fno-omit-frame-pointer flag for easier debugging with tools like ebpf.
One way of course would be to modify the build scripts of each of these projects, but that is a lot of work.
I've come across the possibility to configure gcc with --enable-frame-pointer which restores the old default from the early gcc4.x days of using -fno-omit-frame-pointer.
I've built gcc from source like that and confirmed:
❯ ./bin/gcc -m32 -O3 -Q --help=optimizers | grep omit
-fomit-frame-pointer [disabled]
❯ ./bin/gcc -m64 -O3 -Q --help=optimizers | grep omit
-fomit-frame-pointer [enabled]
Is anyone aware of a possibility to extend the effect of --enable-frame-pointer to the 64bit targets?
I believe you are using an older version of GCC because support of this flag on x64 has been enabled some time ago (see e.g. this commit).
I recently installed LLVM v8.0.0 (on RHEL 7.4). I am going through the LLVM Kaleidoscope tutorial to learn how to use the system, but am running into an issue linking.
Per the tutorial (end of chapter 2), I run:
clang++ -g -O3 kld.cpp `llvm-config --cxxflags` -o kld
It compiles, but the linker fails on:
/tmp/kld-f7264f.o:(.data+0x0): undefined reference to `llvm::EnableABIBreakingChecks'
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
I suspected this may have been an issue with llvm-config, so I also tried using the --ldflags and --system-libs flags, but no luck.
llvm-config --cxxflags gives (reformatted for readability)
-I~/project/llvm-src/include -I~/project/llvm-build/include
-fPIC -fvisibility-inlines-hidden
-std=c++11
-Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
-g
-fno-exceptions -fno-rtti
-D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
Where ~/... is just the path to my home directory (edited for privacy; the actual output is a fullpath). I am working on a shared system that requires I install new software locally.
The tutorial code never references ABI explicitly, so I assume this must be some kind of compiler-flags issue. greping for the missing symbol in non-binary files gives an extern declaration in include/llvm/Config/abi-breaking.h and the real declaration in lib/Support/Error.cpp:
#if LLVM_ENABLE_ABI_BREAKING_CHECKS
int EnableABIBreakingChecks;
#else
int DisableABIBreakingChecks;
#endif
I thought I would try re-compiling, then, with -DLLVM_ENABLE_ABI_BREAKING_CHECKS. That also does that work.
I'm not really clear what the ABI breaking checks are doing in the first place, and this may be way over my C++ comfort level. But how can I silence this error, if I don't need the referenced functionality; or fix it, if i do?
Thanks.
Turns out the answer was hidden in abi-breaking.h:
/* Allow selectively disabling link-time mismatch checking so that header-only
ADT content from LLVM can be used without linking libSupport. */
#if !LLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING
I'm not sure if I'll need libSupport down the line, but compiling with LLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING=1 works for the time being.
Add linkage with LLVMSupport library will also solve this problem.
With this CMake snippet:
find_package(LLVM REQUIRED CONFIG)
message(STATUS "Found LLVM ${LLVM_PACKAGE_VERSION}")
message(STATUS "Using LLVMConfig.cmake in: ${LLVM_DIR}")
add_executable(main main.cpp)
target_link_libraries(main LLVMSupport)
Based on the discussion in llvm irc channel.
Try the following command to compile : clang++ -O3 -c $(llvm-config --cxxflags) source_file.cpp -o obj_code.
Then try linking with this command : clang++ obj_code $(llvm-config --ldflags --libs) -lpthread.
I think linking part doesn't mentioned in the kaleidoscope section. The above solution worked for me.
I don't know the influence and reason why it works. But when I add -DLLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING, the errors disappear.
clang++ xxx -DLLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING
ref:
https://www.coder.work/article/6278120
https://blog.csdn.net/qq_37887537/article/details/112790961
Ubuntu 17.10
GCC Version: 5.4
Bazel Version: 0.9.0
TensorFlow: r1.5
CUDA 8.0 / cuDNN 6 / GTX 1080 Ti
How do I make Bazel use gcc for building TensorFlow from source?
While building, its running into compiler errors like:
error: 'errno' was not declared in this scope
while (nanosleep(&ts, &ts) != 0 && errno == EINTR) {}
Setting --verbose_failures flag, it shows that its not using /usr/bin/gcc-5 or /usr/bin/gcc for compiling
external/local_config_cuda/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc -U_FORTIFY_SOURCE '-D_FORTIFY_SOURCE=1' -fstack-protector -fPIE -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 -DNDEBUG -ffunction-sections -fdata-sections -g0 -DGEMMLOWP_ALLOW_SLOW_SCALAR_FALLBACK '-march=native' '-std=c++11' -g0 -MD -MF
Searching online, I found that the path to gcc and CC, CXX variables must be set in tools/cpp/CROSSTOOL. But where exactly is tools/cpp/CROSSTOOL?? How do I force bazel to use gcc-5?
I know next to nothing about cuda and tensorflow, but tensorflow doesn't use the same C++ toolchain that bazel autoconfigures when compiling with cuda, so the CC env variable trick won't work. The file crosstool_wrapper_driver_is_not_gcc is just a shell wrapper that could in theory still call your gcc (or it will be cuda). I'd run bazel with --subcommands to see the complete invocation of the failing action, then reproduce without bazel, and then go from there.
I was trying some vectorisation after upgrading g++ from version 4.8.5 to 5.4.1. With this flags:
g++ particles-v3.cpp -o v3 -O3 -msse4.2 -mfpmath=sse -ftree-vectorizer-verbose=5 -ffast-math -m32 -march=native -std=c++11
While the same command gives over 4000 lines of detailed information about the vectorization with g++-4.8, with g++-5.4 it does not say anything.
Is there some major change in g++-5 that makes the -ftree-vectorizer-verbose=X unusable, or is there simply somethin wrong in the line? How to change it so that it works?
EDIT:
found out that using -fopt-info-vec-all gives exacty the info I wanted. Thus question solved.
I am using clang 3.5 as distributed by them. I'm using the following command lines to install it in my travis vm:
sudo apt-add-repository 'deb http://llvm.org/apt/precise/ llvm-toolchain-precise-3.5 main'
sudo apt-add-repository 'deb http://llvm.org/apt/precise/ llvm-toolchain-precise-3.5 main'
When I run my test build with optimizations turned on, I get this error:
clang: error: optimization flag '-finline-functions' is not supported
"clang++" -c -x c++ -std=c++1y -Werror -O3 -finline-functions -Wno-inline -Wall -Werror -pthread -fPIC -std=c++1y -DBOOST_ALL_DYN_LINK -DNDEBUG -I"." -I"gamgee" -I"lib/htslib" -o "test/bin/run.test/clang-linux-3.5.0/release/threading-multi/sam_builder_test.o" "test/sam_builder_test.cpp"
I don't get the same error on my mac which runs the older 3.4 version of clang.
Has clang cut support to -finline-functions in 3.5? Is this something specific about this package build? How should one substitute the -finline-functions option for optimized builds with clang-3.5+?
See this commit: http://llvm.org/klaus/clang/commit/6590426aeb5275ec33dac2877f9349bbbb2d4b2e/#0-L-571
Previously, that flag was ignored and the user was not notified. Now the user is notified that it is ignored. You shouldn't have seen any difference in the code generation with or without that flag.
It should only be a warning, but you've upgraded it to an error with -Werror.