I generated a .ll file using llvm-gcc for a Openmp program(written in c).
Then Optimized using opt(version 3.0)
But when I try to execute the optimized .ll file using lli or llvm-ld, getting the following errors,
LLVM ERROR: Program used external function 'GOMP_parallel_start' which could not be resolved!
Here is the step I followed,
$ llvm-gcc -emit-llvm loop11.c -fopenmp -o loop.ll -S
$ opt -O3 loop.ll -o loop.opt.ll -S
$ lli loop.opt.ll
LLVM ERROR: Program used external function 'GOMP_parallel_start' which could not be resolved!
Please help me to solve this problem.
Thanks in advance.
You have to link / load the OpenMP runtime, libgomp in this case.
Related
I am trying to generate a bit code from a c++ source code and running through the just-in-time compiler. When I compile through the clang++ and generate binary executable it runs perfectly but when I generated the bitcode and tried running through the JIT with lli command it generates run-time error. Could you please help me understanding what's going on.
For example: Let example.cpp contains the following code:
#include <iostream>
int main(){
std::cout << "\nHello World!";
return 0;
}
I am using the following command to generate executable which runs perfectly fine.
clang++ example.cpp
I am using the following command to generate the bitcode:
clang++ -S -emit-llvm example.cpp
And then running through the JIT using the following command which generates run-time error:
lli example.ll
I am getting the following access violation error:
Stack dump:
0. Program arguments: lli example.ll
#0 0x00000000025fd9af llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/xpc/llvm/llvm-project1/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:0
#1 0x00000000025fda42 PrintStackTraceSignalHandler(void*) /home/xpc/llvm/llvm-project1/llvm-project/llvm/lib/Support/Unix/Signals.inc:625:0
#2 0x00000000025fb7ca llvm::sys::RunSignalHandlers() /home/xpc/llvm/llvm-project1/llvm-project/llvm/lib/Support/Signals.cpp:68:0
#3 0x00000000025fd329 SignalHandler(int) /home/xpc/llvm/llvm-project1/llvm-project/llvm/lib/Support/Unix/Signals.inc:406:0
#4 0x00007fa75dbdc390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
Segmentation fault (core dumped)
Try compiling with clang++ -S -emit-llvm -fno-use-cxa-atexit example.cpp.
I think it's probably because clang and gcc try prefer __cxa_atexit to
atexit by default (these are functions used for cleaning up global objects when a program exits). Meaning you'll get a linker error if your libc implementation doesn't support the former. So disabling the use-cxa-atexit flag should work.
It seems that it's a library linking issue. Try to use the followings:
Try lli -force-interpreter example.ll instead of lli example.ll
When JIT can't work properly, you should try interpreter.
if the following err:
LLVM ERROR: Could not resolve external global address: __dso_handle
Then add -fno-use-cxa-atexit to clang flags, reasons from [LLVMdev] MCJIT/interpreter and iostream.
After retry lli -force-interpreter example.ll if still have some errors like LLVM ERROR: Tried to execute an unknown external function: .... Then you should recompile LLVM with ffi library enabled. See the following for reasons: Advice on Packaging LLVM¶
and [LLVMdev] lli --force-interpreter does not find external function
I am trying to run the makefile of a program in Fortran 77 that I did not write.
It specifies the following flags:
FLT_FLAGS = -native -libmil
and then uses them to compile a Fortran 77 program:
f77 -O -native -libmil -c a2.f
but fails:
f77: error: unrecognized command line option ‘-native’
makefile:107: recipe for target 'vg.a(a2.o)' failed
make: *** [vg.a(a2.o)] Error 1
The only thing I have been able to find with respect to this issue is that -native is obsolete, and maybe that's why gfortran (f77) does not recognize it: https://docs.oracle.com/cd/E37069_01/html/E37076/aevft.html#scrolltoc
You are using gfortran version 5.4. I wouldn't call f77 but gfortran directly if I were you.
The correct gfortran option similar to -native in some other compilers is -march=native or -mtune=native. See the manual and GCC: how is march different from mtune?
Don't forget to use other optimization flags like -O2 or -O3. The native option alone is not too useful.
Running the following code with clang++ -S -emit-llvm main.cpp && lli main.ll on Linux(Debian)
#include <future>
int main () {
return std::async([]{return 1;}).get();
}
fails to run on lli due to the following error:
LLVM ERROR: Cannot select: 0xd012e0:
i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i8** #_ZSt15__once_callable> 0 [TF=10]
0xd020c0: i64 = TargetGlobalTLSAddress<i8** #_ZSt15__once_callable> 0 [TF=10]
In function: _ZSt9call_onceIMNSt13__future_base13_State_baseV2EFvPSt8functionIFSt10unique_ptrINS0_12_Result_baseENS4_8_DeleterEEvEEPbEJPS1_S9_SA_EEvRSt9once_flagOT_DpOT0_
Questions:
What does it mean?
Are there any compiler-flags that fix this problem?
using -stdlib=libc++ compiles and runs successfully*; what specific features is libstdc++ using that cause this issue ?
EDIT:
The motivation behind this question is to understand the differences between libc++ and libstdc++ that leads to this specific error message (on Linux) in llvm's orcjit.
On OSX gcc has been deprecated and clang uses by default libc++.
To reproduce this error on OSX you probably have to install gcc & use -stdlib=libstdc++.
Here is the llvm-ir (it's unfortunately to big to embed it here directly)
EDIT:
The error turned out to be caused by the lack of TLS support in the JITer. This answer describes another problem concerned with linking and lli.
If you have a look at the generated IR from clang++ -std=c++11 -S -emit-llvm test.cpp, you will find that many of the symbols, e.g. _ZNSt6futureIiE3getEv, are only declared, but never defined. The linker is never called, since -S "Only run[s] preprocess and compilation steps" (clang --help).
lli only executes the IR Module and does no "implicit" linking, how is it supposed to know which libraries to link in?
There are different solutions to this, depending on why you are using lli:
compile and link the IR Module: llc main.cpp && clang++ -lpthread main.s (pthread is required s. What is the correct link options to use std::thread in GCC under linux?)
(unconfirmed) use LD_PRELOAD="x.so y.so" to force-load the libraries before running lli
JIT the module programmatically and use LoadLibraryPermanently(nullptr) (adds symbols of the program into the search space) and LoadLibraryPermanently(file, err) for additional libs (s. http://llvm.org/docs/doxygen/html/classllvm_1_1sys_1_1DynamicLibrary.html)
I can only guess as to why libc++ works for you since it fails on my machine, but presumably it's the case because it is loaded into lli already and lli calls sys::DynamicLibrary::LoadLibraryPermanently(nullptr) to add the program's symbols to its JIT search space (s. https://github.com/llvm-mirror/llvm/blob/release_40/tools/lli/OrcLazyJIT.cpp#L110).
The LLVM-dev mailinglist pointed out:
What does it mean?
The llvm-backend in orcjit does currently not support thread-local storage(TLS)
a minimal example is:
extern thread_local int tls;
int main() {
tls = 42;
return 0;
}
using -stdlib=libc++ compiles and runs successfully*; what specific features is libstdc++ using that cause this issue ?
this works because libc++ future::get implementation does not use thread_local keyword.
Are there any compiler-flags that fix this problem?
currently there is no solution.
Using lli -relocation-model=pic trades this problem with a relocation failure.
I'm trying to use cilkscreen to detect some race conditions in a code.
I'm compiling my code using
g++-5 -g foo.cpp -fcilkplus -std=c++14 -lcilkrts -ldl -O2
However, when I launch cilkscreen I get the following error message:
cilkview ./a.out
Cilkview: Generating scalability data
Cilkview Scalability Analyzer V2.0.0, Build 4421
1100189201
Error: No Cilk code found in program
Should I add some more option to g++ ? Or does cilkscreen only works with code compiled with icc ?
FWIW: I'm using
gcc version 5.3.1 20160301 [gcc-5-branch revision 233849] (SUSE Linux)
Cilkscreen/cilkview works only with icc/icpc.
I am trying to compile a big solver using a makefile. When typing make, the following command gets executed:
mpif90 -O2 -fpp -I/somePath/ -c precision.F90
I get the following error:
gfortran: error: unrecognized command line option ‘-fpp’
I typed which mpif90 to see where it is pointing to:
/usr/local/intel14/impi/4.1.3.048/intel64/bin/mpif90
I tried to manually enter the command to make sure it did not have anything to do with the makefile and I got the same error. Why is gfortran being called? It must be some linking error but I can't figure it out.
The comments put me on the right track. I did not know mpif90 was just a wrapper.
$ /usr/local/inter14/impi/4.1.3.048/intel64/bin/mpif90 -v
mpif90 for the Intel(R) MPI Library 4.1 for Linux*
Copyright(C) 2003-2014, Intel Corporation. All rights reserved.
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gcc5.2/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local/gcc5.2 --disable-multilib
Thread model: posix
gcc version 5.2.0 (GCC)
I asked the code's author to do the same, the output pointed to an intel compiler. So what remains is to link ifort. This fixed it for me (bash shell):
export I_MPI_F90=ifort
You can just use the alternative
/usr/local/intel14/impi/4.1.3.048/intel64/bin/mpiifort