Problems building the release/10.x branch

[mppf]

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.

[richardmembarth]

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?

[mppf]

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...

[mppf]

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.

[mppf]

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

[mppf]

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());
      |                                                      ^~~~~~~~~~~~~~

[mppf]

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.

[richardmembarth]

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?

[mppf]

@richardmembarth - yes, thanks for your help (and updating the README). I have release/10.x building now, so I'm closing this issue.

[richardmembarth]

Great. Btw, master on RV should work with master on llvm - lagging by some weeks/months.