/constness/array/array_01.cpp -o array_01_cpp_m2r_dbg.ll && /usr/local/llvm14/bin/opt -mem2reg -S array_01_cpp_m2r_dbg.ll -o array_01_cpp_m2r_dbg.ll FAILED: test/llvm_test_code/constness/array/array_01_cpp_m2r_dbg.ll /wrkdirs/usr/ports/devel/phasar/work/.build/test/llvm_test_code/constness/array/array_01_cpp_m2r_dbg.ll cd /wrkdirs/usr/ports/devel/phasar/work/.build/test/llvm_test_code/constness/array && /usr/bin/c++ -std=c++17 -fno-discard-value-names -emit-llvm -S -Xclang -disable-O0-optnone -g /wrkdirs/usr/ports/devel/phasar/work/phasar-1222/test/llvm_test_code/constness/array/array_01.cpp -o array_01_cpp_m2r_dbg.ll && /usr/local/llvm14/bin/opt -mem2reg -S array_01_cpp_m2r_dbg.ll -o array_01_cpp_m2r_dbg.ll array_01_cpp_m2r_dbg.ll:13:16: warning: ptr type is only supported in -opaque-pointers mode store i32 0, ptr %retval, align 4 ^ /usr/local/llvm14/bin/opt: array_01_cpp_m2r_dbg.ll:13:16: error: expected type store i32 0, ptr %retval, align 4 ^
Looks odd in a way that possibly is the port's or upstream's problem: /usr/bin/c++ . . . && /usr/local/llvm14/bin/opt . . . Using llvm14's opt with llvm15's cc++ (clang++) -emit-llvm output might not be guaranteed to be coherent.
(In reply to Mark Millard from comment #1) Looking at: http://ampere3.nyi.freebsd.org/build.html?mastername=131arm64-default&build=99b0009cf678 (for an environment that has /usr/bin/c++ being llvm14), the build worked. It looks like the c++ compiler and opt should be from the same llvm* vintage, at least matching for the major version.
(In reply to Mark Millard from comment #1) No indeed. Care should be taken to not mix different versions of llvm's bitcode (.bc or .ll files. That is: /usr/bin/c++ -std=c++17 -fno-discard-value-names -emit-llvm -S -Xclang -disable-O0-optnone -g /wrkdirs/usr/ports/devel/phasar/work/phasar-1222/test/llvm_test_code/constness/array/array_01.cpp -o array_01_cpp_m2r_dbg.ll && /usr/local/llvm14/bin/opt -mem2reg -S array_01_cpp_m2r_dbg.ll -o array_01_cpp_m2r_dbg.ll will only work if /usr/bin/c++ and /usr/local/llvm14/bin/opt are the same version, llvm 14. It is advisable to use /usr/local/llvm/bin/clang++ to compile the .cpp to .ll instead.
I think that llvm.mk should have an option to set CC/CPP/CXX as well, or this should be always done.
(In reply to Yuri Victorovich from comment #4) Why use part of a devel/llvm* but not the other parts of the same? The infrastructure allows specifying that a specific devel/llvm* be used as I remember. It also allows specifying to use the default devel/llvm* version in a uniform manor, as I remember. That updates when the infrastructure changes the default. Is this a context were other software involved forces what can be used in order to have a valid combination?
The port is now using matching C++ compiler. Thanks everybody for comments.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=c748b7ef83ea213372740636c998f351825098c8 commit c748b7ef83ea213372740636c998f351825098c8 Author: Yuri Victorovich <yuri@FreeBSD.org> AuthorDate: 2023-06-19 14:06:10 +0000 Commit: Yuri Victorovich <yuri@FreeBSD.org> CommitDate: 2023-06-19 14:08:59 +0000 devel/phasar: Fix build on 14 by using C++ compiler provided by llvm package Build was failing because C++ compiler was from a different llvm version than the llvm library provided by USES=llvm. PR: 272075 devel/phasar/Makefile | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)