How do I fix the following warning produced by clang when compiling LLVM code?
$ clang test.ll
warning: overriding the module target triple with x86_64-pc-linux-gnu [-Woverride-module]
1 warning generated.
This happens when the LLVM IR code doesn't explicitly specify a compilation target. To fix it, specify the target triple at the top of your .ll file, for example:
target triple = "x86_64-pc-linux-gnu"
Be sure to replace x86_64-pc-linux-gnu with the target shown in your warning message. (You can also get the target by running llvm-config --host-target.)
Related
I need to use meson build system, for a project, I am forced to give CXXFLAGS via, meson.build itself. According to offical meson documentation To add compiler options via add_project_arguments meson I need to give clang and opt options in the meson.build itself. This is how I do it in meson.build, I am supposed to use clang-14. The problem is as per the error log file, It accepts the clang options ( Those not prefixed by -mllvm ) like -O3 or -ftlo, because I see no error log for these clang options, but the options with ( -mllvm -some_opt_option ) gives me error clang-14: error: unknown argument: 'some_opt_option' how do I get past this error, and make meson to accept these opt options and not just clang options.
if cc.get_id() == 'clang'
# Thread safety annotation
add_project_arguments('-O3', language : 'cpp')
I am using macOS High Sierra version 10.13.4. While installing "RcppArmadillo"package, I get the following two WARNING messages :
checking whether /usr/local/clang6/bin/clang++ -Wall accepts -g... (cached) yes
checking whether g++ version is sufficient... almost
configure: WARNING: Compiler self-identifies as being compliant with GNUC extensions but is not g++.
checking for macOS... found
checking for macOS Apple compiler... not found
checking for clang compiler... found
checking for OpenMP compatible version of clang... found and suitable
checking LAPACK_LIBS... R-supplied partial LAPACK found
configure: WARNING: Some complex-valued LAPACK functions may not be available
When I type "gcc --version" on my terminal, I get
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.2)
Target: x86_64-apple-darwin17.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
And my Makevars file in R looks like:
FLIBS=-L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin16/6.3.0 -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm
F77 = /usr/local/bin/gfortran
FC = $F77
CXX = /usr/local/clang6/bin/clang++ -Wall
LDFLAGS=-L/usr/local/clang6/lib
CC= /usr/local/clang6/bin/clang
SHLIB_CXXLD=ccache /usr/local/clang6/bin/clang++
CXX11 = /usr/local/clang6/bin/clang++
CXX98 = /usr/local/clang6/bin/clang++
CXX14 = /usr/local/clang6/bin/clang++
How can I remove these two WARNING signs?
In short, these are warnings and not errors. Moreover, these warnings do not matter.
Let's talk about what each warning means...
First Warning
configure: WARNING: Compiler self-identifies as being compliant with GNUC extensions but is not g++.
This is stating that the compiler defined in the Makevars file's CXX variable is identifying as gcc but is not the gcc compiler. In essence, each compiler has its own predefined header, see Section 3.7.2 Common Predefined Macros of The C Preprocessor, and this check is focused on verifying that a modern gcc compiler is selected. However, it's hard to check the presence of a compiler if the compiler is lying about who it is.
For details on the origin, see discussion in the issue Add a check message success in config after g++version check #183 and the commit the default message on the g++ test).
Second Warning
configure: WARNING: Some complex-valued LAPACK functions may not be available
Within this warning, there is a complaint that the underlying Linear Algebra PACKage is the same one that is shipped with R. Unfortunately, the LAPACK that is shipped with R is severely limited and a bit out of date. So, the check here is hoping for an external LAPACK being present via either OpenBLAS, Intel MKL, or ATLAS. Due to the way this check is structured, unless you are compiling R from source -- that is you opt not to use the binary provided by CRAN -- there is no way to avoid the hiccup.
Simply put, the CRAN binary looks for the LAPACK in a specific location. Switching to another LAPACK would require the establishment of a symbolic link to the existing lRlapack location, which is what the check searches for. Though, it isn't advisable doing such a symbolic link. (Sorry vecLib lovers!)
If you are interested in compiling from source, consider viewing Section A.3 Linear algebra of R Installation and Administration, which describes the procedure for using external LAPACKs.
I want to use distcc to compile code from my Mac to a bunch of Linux hosts, but I can't figure out how to make everything "line up". I've successfully used distcc from Mac to Mac, so I have a general idea of how to set things up.
I'm using Clang 4.0 and have it installed and working on both Mac and Linux. The following command compiles fine without the distcc at the beginning, but after adding distcc, I get the following issues:
distcc /Users/xaxxon/Downloads/clang+llvm-4.0.0-x86_64-apple-darwin/bin/clang++ -I/usr/local/include -I/Users/xaxxon/v8toolkit/./include -I/Users/xaxxon/v8/include -stdlib=libc++ -g -Werror=return-type -g -std=gnu++1z -o CMakeFiles/v8toolkit_static.dir/src/v8toolkit.cpp.o -c /Users/xaxxon/v8toolkit/src/v8toolkit.cpp
I'm not sure what compiler is being picked up on Linux, nor do I know how to find out. It's possible it's picking up GCC instead of Clang.
My first concern is this:
clang: warning: argument unused during compilation: '-stdlib=libc++'
My first error is:
In file included from /Users/xaxxon/v8toolkit/src/v8toolkit.cpp:5:
In file included from /usr/include/assert.h:44:
In file included from /Users/xaxxon/Downloads/clang+llvm-4.0.0-x86_64-apple-darwin/bin/../include/c++/v1/stdlib.h:94:
/usr/include/stdlib.h:250:20: error: blocks support disabled - compile with -fblocks or pick a deployment target that supports them
int atexit_b(void (^)(void)) __attribute__((availability(macosx,introduced=10.6)));
The next error I get (which becomes the first error if I manually add -fblocks to the compilation command (which isn't needed on a native Mac build) is:
/Users/xaxxon/Downloads/clang+llvm-4.0.0-x86_64-apple-darwin/bin/../include/c++/v1/__tuple:289:13: error: unknown type name '__type_pack_element'
typedef __type_pack_element<_Ip, _Types...> type;
^
/Users/xaxxon/Downloads/clang+llvm-4.0.0-x86_64-apple-darwin/bin/../include/c++/v1/__tuple:289:32: error: expected member name or ';' after declaration specifiers
typedef __type_pack_element<_Ip, _Types...> type;
~~~~~~~~~~~~~~~~~~~~~~~~~~~^
/Users/xaxxon/Downloads/clang+llvm-4.0.0-x86_64-apple-darwin/bin/../include/c++/v1/__tuple:356:43: error: use of undeclared identifier '__type_pack_element'
typename _ApplyFn::template __apply<__type_pack_element<_Idx, _Types...>>...
^
/Users/xaxxon/Downloads/clang+llvm-4.0.0-x86_64-apple-darwin/bin/../include/c++/v1/__tuple:357:6: error: expected a type
>;
I don't understand if I'm doing something fundamentally wrong or if there's something small I'm missing which is making the Linux compiler act differently.
I just made sure to have Clang on Linux in the same named directory and now am only getting the -fblocks and unused during compilation -stdlib=libc++ issues.
I can get everything to compile (albeit with warnings), but when it links, I get:
ld: warning: ignoring file CMakeFiles/v8toolkit_shared.dir/src/debugger.cpp.o, file was built for
unsupported file format ( 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 ) which is not the architecture being linked
(x86_64): CMakeFiles/v8toolkit_shared.dir/src/debugger.cpp.o
As long as you specify the -target flag, you can even cross-compile, because Clang is a native cross compiler.
Cross-compilation using Clang
Adding the -target flag fixes everything! In my case, for Mac OS X v10.11 (El Capitan), the target triple is:
-target x86_64-apple-darwin15.6.0
for a build command of:
distcc /Users/xaxxon/Downloads/clang+llvm-4.0.0-x86_64-apple-darwin/bin/clang++ -Dv8toolkit_shared_EXPORTS -I/usr/local/include -I/Users/xaxxon/v8toolkit/./include -isystem /Users/xaxxon/v8/include -stdlib=libc++ -g -Werror=return-type -target x86_64-apple-darwin15.6.0 -g -fPIC -std=gnu++1z -o CMakeFiles/v8toolkit_shared.dir/src/v8toolkit.cpp.o -c /Users/xaxxon/v8toolkit/src/v8toolkit.cpp
You can get the current host's target by typing clang -v:
$ clang -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-apple-darwin15.6.0 <<==== THIS LINE HERE
Thread model: posix
InstalledDir: /Users/xaxxon/Downloads/clang+llvm-4.0.0-x86_64-apple-darwin/bin
The following CMake lines will grab (and print) the triple for the current machine:
# Get the target triple for the current host by calling clang -v and then stripping out the Target: value from its output. CMake regex syntax is quite limited.
execute_process(COMMAND ${CMAKE_CXX_COMPILER} -v ERROR_VARIABLE CLANG_VERSION_INFO)
string(REGEX REPLACE ".*Target:[\r\n\t ]*([^\r\n\t]*).*Thread model.*" "\\1" TARGET_TRIPLE ${CLANG_VERSION_INFO})
message(STATUS "TARGET TRIPLE: '${TARGET_TRIPLE}' END")
Much thanks to #duskwuff and oftc.net #llvm for help figuring this out!
I am developing an LLVM pass and want to run it as a plugin via the Clang LLVM driver:
clang -Xclang -load -Xclang myPlugin.so ...
At first I got an error similar to that described here
undefined symbol for self-built llvm opt?
After applying the flag -D_GLIBCXX_USE_CXX11_ABI=0 as suggested, I'm getting this error:
error: unable to load plugin 'myPlugin.so': 'myPlugin.so: undefined symbol: _ZNK4llvm12FunctionPass17createPrinterPassERNS_11raw_ostreamERKSs
This page suggests that there may be an ABI compatibility issue (which I don't fully understand)
http://clang-developers.42468.n3.nabble.com/Loading-Static-Analyzer-plugin-fails-with-CommandLine-Errors-td4034194.html
My objective is to compile the pass with either GCC or Clang and run it with the system Clang installation (Ubuntu 16.04, LLVM 3.8) rather than building Clang/LLVM from source.
The problem could come from multiple clang installations. The clang version you have used to compile your plugin may be different from the clang called in
clang -Xclang -load -Xclang myPlugin.so ...
If you use cmake to build your plugin, then
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
will generate the file compile_commands.json that will contain the llvm version you have used. bear make or make -n are alternatives if you don't use cmake for your plugin.
If compile_commands.json contains for example
"command": "c++ -c -I/usr/lib/llvm-4.0/include ..."
and if clang -v is clang version 3.8.0, you are likely to obtain this error message especially if llvm::FunctionPass::createPrinterPass is in llvm-4.0 and not in llvm-3.8.
A solution may be to compile with
clang-xxx -Xclang -load -Xclang myPlugin.so ...
where clang-xxx contains the llvm-xxx that is referenced in compile_commands.json.
I was receiving that error because first argument I passed into the RegisterPass had the same name as the pass itself:
static RegisterPass<MyPass> X("MyPass", "DPVariableNamePass", false, false);
Changing it fixed the issue:
static RegisterPass<MyPass> X("my-pass", "DPVariableNamePass", false, false);
Maybe it helps
Under Ubuntu 64 bit I got
llc --version
LLVM (http://llvm.org/):
LLVM version 3.1
Optimized build with assertions.
Built Oct 15 2012 (18:15:59).
Default target: x86_64-pc-linux-gnu
Host CPU: btver1
Registered Targets:
arm - ARM
mips - Mips
mips64 - Mips64 [experimental]
mips64el - Mips64el [experimental]
mipsel - Mipsel
thumb - Thumb
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
I can't do this
clang -march=arm -x c++ /tmp/cpp.cpp
error: unknown target CPU 'arm'
I'm missing something here ? Why I can't compile for ARM ?
-march is LLVM's internal tools command line option and is not connected with clang at all. If you need to compile for other target you need to specify the target triplet. This can be done in several ways (I do not remember offhand, whether they work with 3.1, but they definitely work with 3.2):
Make a link from clang to your-target-triple-clang, e.g. to
arm-none-linux-gnueabi-clang and compile everything via it
Provide -target option, e.g. clang -target arm-none-linux-gnueabi
To get a list of options of the clang compiler, use:
clang -cc1 -help
To specify the target, use -triple:
clang -cc1 -triple "arm-vendor-os" filename
where "vendor" and "os" should be replaced with the actual vendor and OS name. It can also be replaced with unknown.
-triple is a string of the form ARCHITECTURE-VENDOR-OS or ARCHITECTURE-VENDOR-OS-ENVIRONMENT. For example: x86_64-apple-darwin10
the llvm linker links for the host, which is only one of the targets, it wont link to every target in the list. it will definitely compile for any target. Basically clang goes from C/C++ to bytecode, then llc takes bytecode and makes assembly for the specific target (new experrimental option to take the bytecode straight to object file) then you need to get a cross assembler and a cross linker to take it the final mile (I use gnu binutils). Unfortunately I found that clang to bytecode is not completely generic (I had hoped and expected that it would be), it does in fact change the target independent output based on the target. The example below using the host triple instead of using -march allowed for my examples to build properly on more hosts.
ARMGNU?=arm-none-eabi
LOPS = -Wall -m32 -emit-llvm -ccc-host-triple $(ARMGNU)
OOPS = -std-compile-opts
LLCOPS = -march=thumb -mtriple=$(ARMGNU)
clang $(LOPS) -c blinker03.c -o blinker03.clang.bc
opt $(OOPS) blinker03.clang.bc -o blinker03.clang.thumb.opt.bc
llc $(LLCOPS) blinker03.clang.thumb.opt.bc -o blinker03.clang.thumb.opt.s
$(ARMGNU)-as blinker03.clang.thumb.opt.s -o blinker03.clang.thumb.opt.o
$(ARMGNU)-ld -o blinker03.clang.thumb.opt.elf -T memmap vectors.o blinker03.clang.thumb.opt.o
I have not, but before long will experiment with using the llc straight to object (actually I tried it on a simple test but have not used it on anything larger or posted it anywhere).
You're confusing your flags. clang's -march= wants a processor family. You probably meant to use clang -arch arm instead.
As this comment says this option it's not supported yet under linux, for now.
"-arch arm" is equivalent to "-arch armv4t" in clang. I suppose that a generic "arm" target is not allowed with "-march=", which should require something more precise, such as "armv6", "thumbv7", "armv4t", ...
Try selecting a specific subarch.
Starting Clang 11 (trunk), the list of supported target architectures could be handily printed using the newly added -print-targets flag.