Problems building the release/10.x branch
mppf opened this issue · comments
I'm trying to build a recent RV with a recent LLVM. I've tried checking out the release/10.x branch of both and putting rv into llvm-project/llvm/tools/rv & then supplying some cmake arguments to activate RV -DRV_ENABLE_CRT=on -DLLVM_ENABLE_CXX1Y=on -DLLVM_CXX_STD:STRING=c++14. Are these versions expected to work? It would be nice if the top-level README.md had some build instructions (or maybe a link to the wiki with those to make it easier to update?)
Anyway the cmake run prints out this error:
-- Registering Bye as a pass plugin (static build: OFF)
Traceback (most recent call last):
File "", line 22, in
IndexError: list index out of range
Of course that one might be harmless...
Then, later in the build, I am seeing these errors:
In file included from /home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/tools/rv/vecmath/crt.c:123:
/home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/udivsi3.c:15:16: error: typedef redefinition with different types ('su_int' (aka 'unsigned int') vs 'du_int' (aka 'unsigned long'))
typedef su_int fixuint_t;
^
/home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/udivdi3.c:15:16: note: previous definition is here
typedef du_int fixuint_t;
^
In file included from /home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/tools/rv/vecmath/crt.c:123:
/home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/udivsi3.c:16:16: error: typedef redefinition with different types ('si_int' (aka 'int') vs 'di_int' (aka 'long'))
typedef si_int fixint_t;
^
/home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/udivdi3.c:16:16: note: previous definition is here
typedef di_int fixint_t;
^
In file included from /home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/tools/rv/vecmath/crt.c:123:
In file included from /home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/udivsi3.c:17:
/home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/int_div_impl.inc:16:27: error: redefinition of '__udivXi3'
static __inline fixuint_t __udivXi3(fixuint_t n, fixuint_t d) {
^
/home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/int_div_impl.inc:16:27: note: previous definition is here
static __inline fixuint_t __udivXi3(fixuint_t n, fixuint_t d) {
^
In file included from /home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/tools/rv/vecmath/crt.c:123:
In file included from /home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/udivsi3.c:17:
/home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/int_div_impl.inc:45:27: error: redefinition of '__umodXi3'
static __inline fixuint_t __umodXi3(fixuint_t n, fixuint_t d) {
^
/home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/int_div_impl.inc:45:27: note: previous definition is here
static __inline fixuint_t __umodXi3(fixuint_t n, fixuint_t d) {
^
In file included from /home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/tools/rv/vecmath/crt.c:126:
/home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/umodsi3.c:15:16: error: typedef redefinition with different types ('su_int' (aka 'unsigned int') vs 'du_int' (aka 'unsigned long'))
typedef su_int fixuint_t;
^
/home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/umoddi3.c:15:16: note: previous definition is here
typedef du_int fixuint_t;
^
In file included from /home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/tools/rv/vecmath/crt.c:126:
/home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/umodsi3.c:16:16: error: typedef redefinition with different types ('si_int' (aka 'int') vs 'di_int' (aka 'long'))
typedef si_int fixint_t;
^
/home/mppf/w/llvm2/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/umoddi3.c:16:16: note: previous definition is here
typedef di_int fixint_t;
Is this supposed to work? Am I doing something wrong?
Thanks.
The new llvm-project directory structure is different to the old structure. I've updated the README to reflect this change.
There is no need to specify LLVM_ENABLE_CXX1Y (doesn't exist anymore) or LLVM_CXX_STD. Instead you need to specify the source location of RV to CMake using -DLLVM_EXTERNAL_PROJECTS="rv" -DLLVM_EXTERNAL_RV_SOURCE_DIR=llvm-project/rv.
Does this solve your issue?
I'm seeing similar problems with the release_90 branches.
Back to the 10.x branches, the Bye error is present after making the suggested cmake changes.
Then, the build completed successfully, but I don't think it build RV at all. Of course I might have done something wrong...
Ah, I was doing something wrong. (moving the directory messed up other scripting). I needed to give the full path in -DLLVM_EXTERNAL_RV_SOURCE_DIR - it might be worth updating the README.md to indicate that (otherwise it looks like one should literally put what is there but that does not work. there might be a different relative path that will generally work though).
Anyway, once my build completed, I see the same errors along these lines:
In file included from /home/mppf/w/llvm-debug/third-party/llvm/llvm-project/rv/vecmath/crt.c:123:
/home/mppf/w/llvm-debug/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/udivsi3.c:15:16: error: typedef redefinition with different types ('su_int' (aka 'unsigned int') vs 'du_int' (aka 'unsigned long'))
typedef su_int fixuint_t;
^
/home/mppf/w/llvm-debug/third-party/llvm/llvm-project/llvm/../compiler-rt//lib/builtins/udivdi3.c:15:16: note: previous definition is here
typedef du_int fixuint_t;
^
It looks to me like rv/vecmath/crt.c #includes a variety of C files and some of these are making a typedef with the same name.
I suspect that the way to resolve this (in the short term) is to stop providing -DRV_ENABLE_CRT=on.
I tried building without -DRV_ENABLE_CRT=on and I get this different error:
[ 96%] Generating ../lib/vla_sleef_dp.gen.cpp
import-im6.q16: unable to open X server `' @ error/import.c/ImportImageCommand/359.
/home/mppf/w/llvm-debug/third-party/llvm/llvm-project/rv/tools/gen_cpp.py: 4: cppFileName,: not found
/home/mppf/w/llvm-debug/third-party/llvm/llvm-project/rv/tools/gen_cpp.py: 6: Syntax error: "(" unexpected
make[3]: *** [tools/rv/vecmath/CMakeFiles/gensleef.dir/build.make:142: tools/rv/lib/vla_sleef_dp.gen.cpp] Error 2
make[2]: *** [CMakeFiles/Makefile2:40225: tools/rv/vecmath/CMakeFiles/gensleef.dir/all] Error 2
It seems that PYTHON_EXECUTABLE is not being set in vecmath/CMakeLists.txt for some reason.
I added
SET (PYTHON_EXECUTABLE "/usr/bin/python")^M
to vecmath/CMakeLists.txt after the other SET commands at the top and that seemed to fix it. But I am pretty sure this is not the right solution.
After I did that, I see
/home/mppf/w/llvm-debug/third-party/llvm/llvm-project/rv/src/intrinsics.cpp: In function ‘std::string MangleType(const llvm::Type&)’:
/home/mppf/w/llvm-debug/third-party/llvm/llvm-project/rv/src/intrinsics.cpp:26:16: error: ‘const class llvm::Type’ has no member named ‘getVectorIsScalable’
26 | return (Ty.getVectorIsScalable() ? "nxv" : "v") + std::to_string(Ty.getVectorElementCount().Min) + MangleType(Ty);
| ^~~~~~~~~~~~~~~~~~~
/home/mppf/w/llvm-debug/third-party/llvm/llvm-project/rv/src/intrinsics.cpp:26:73: error: ‘const class llvm::Type’ has no member named ‘getVectorElementCount’
26 | (Ty.getVectorIsScalable() ? "nxv" : "v") + std::to_string(Ty.getVectorElementCount().Min) + MangleType(Ty);
| ^~~~~~~~~~~~~~~~~~~~~
/home/mppf/w/llvm-debug/third-party/llvm/llvm-project/rv/src/intrinsics.cpp: In function ‘const llvm::Function* rv::GetCallee(const llvm::Value&)’:
/home/mppf/w/llvm-debug/third-party/llvm/llvm-project/rv/src/intrinsics.cpp:64:54: error: ‘const class llvm::CallInst’ has no member named ‘getCalledValue’
64 | const auto * func = dyn_cast<const Function>(call->getCalledValue());
| ^~~~~~~~~~~~~~
Oh, I have accidentally been building RV release/10.x with the master branch of LLVM.
I think that means that the above problems are ones RV will have to face when creating release/11.x. Anyway I will close this issue if fixing my confusion there solves the problem.
As you have realized, you mixed branches.
PYTHON_EXECUTABLE is set by llvm, no need to set this yourself.
I guess this solves this issue?
@richardmembarth - yes, thanks for your help (and updating the README). I have release/10.x building now, so I'm closing this issue.
Great. Btw, master on RV should work with master on llvm - lagging by some weeks/months.