[PATCH] D64579: [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

Hello @smeenai , this commit causes LLVM to fail to build when set set `-D 
BUILD_SHARED_LIBS=ON`. Here is the failing CMake and Ninja invocation:

  /tools/build/cmake-3.14.5/bin/cmake \
  -G Ninja  \
  -D CMAKE_MAKE_PROGRAM=/tools/build/ninja-1.9.0/ninja \
  -D CMAKE_C_COMPILER=/usr/lib/llvm-7/bin/clang \
  -D CMAKE_CXX_COMPILER=/usr/lib/llvm-7/bin/clang++ \
  -D CMAKE_BUILD_TYPE=Release \
  -D CMAKE_INSTALL_PREFIX=/work/upstream/install \
  -D LLVM_TOOL_CLANG_BUILD=ON \
  -D LIBCXX_INCLUDE_BENCHMARKS=ON \
  -D BUILD_SHARED_LIBS=ON \
  -D LLVM_ENABLE_ASSERTIONS=ON \
  -D LLVM_TARGETS_TO_BUILD=X86 \
  /work/upstream/llvm-project/llvm
  
  /tools/build/ninja-1.9.0/ninja -v install

I am able to successfully build LLVM when I change to `-D 
BUILD_SHARED_LIBS=OFF`.

The outputted errors happen during link time of `lib/libclang_shared.so.9svn`:

  FAILED: lib/libclang_shared.so.9svn
  
  ...
  
  tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenModule.cpp.o: 
In function `llvm::cl::opt >::~opt()':
  
CodeGenModule.cpp:(.text._ZN4llvm2cl3optIbLb0ENS0_6parserIbEEED2Ev[_ZN4llvm2cl3optIbLb0ENS0_6parserIbEEED2Ev]+0x7):
 undefined reference to `vtable for llvm::cl::Option'
  tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenModule.cpp.o: 
In function `clang::CodeGen::CodeGenModule::CodeGenModule(clang::ASTContext&, 
clang::HeaderSearchOptions const&, clang::PreprocessorOptions const&, 
clang::CodeGenOptions const&, llvm::Module&, clang::DiagnosticsEngine&, 
clang::CoverageSourceInfo*)':
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x57a):
 undefined reference to `llvm::FoldingSetBase::FoldingSetBase(unsigned int)'
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x5cc):
 undefined reference to `llvm::Type::getVoidTy(llvm::LLVMContext&)'
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x5d7):
 undefined reference to `llvm::Type::getInt8Ty(llvm::LLVMContext&)'
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x5e3):
 undefined reference to `llvm::Type::getInt16Ty(llvm::LLVMContext&)'
  
  ... (clipped thousands of similar errors)
  
  
WhitespaceManager.cpp:(.text._ZN5clang6formatL18AlignTokenSequenceIRZNS0_17WhitespaceManager28alignConsecutiveDeclarationsEvE3$_2EEvjjjOT_RN4llvm11SmallVectorINS2_6ChangeELj16EEE+0x129):
 undefined reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, 
unsigned long)'
  
tools/clang/tools/clang-fuzzer/handle-cxx/CMakeFiles/obj.clangHandleCXX.dir/handle_cxx.cpp.o:
 In function `clang_fuzzer::HandleCXX(std::__cxx11::basic_string, std::allocator > const&, std::vector > const&)':
  
handle_cxx.cpp:(.text._ZN12clang_fuzzer9HandleCXXERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorIPKcSaISA_EE+0x67):
 undefined reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, 
unsigned long)'
  
handle_cxx.cpp:(.text._ZN12clang_fuzzer9HandleCXXERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorIPKcSaISA_EE+0x32b):
 undefined reference to `llvm::MemoryBuffer::getMemBuffer(llvm::StringRef, 
llvm::StringRef, bool)'
  
handle_cxx.cpp:(.text._ZN12clang_fuzzer9HandleCXXERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorIPKcSaISA_EE+0x669):
 undefined reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, 
unsigned long)'
  clang: error: linker command failed with exit code 1 (use -v to see 
invocation)


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64579/new/

https://reviews.llvm.org/D64579



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

Here's my proposed logic as actual CMake code. @mikhail.ramalho if you can get 
your code to emit the version string I made a `TODO` placeholder for it in the 
3rd block below.

  diff --git a/llvm/cmake/modules/FindZ3.cmake b/llvm/cmake/modules/FindZ3.cmake
  index 5c6d3f0..f913686 100644
  --- a/llvm/cmake/modules/FindZ3.cmake
  +++ b/llvm/cmake/modules/FindZ3.cmake
  @@ -30,7 +30,23 @@ find_program(Z3_EXECUTABLE z3
  PATH_SUFFIXES bin
  )
   
  -if(Z3_INCLUDE_DIR AND Z3_LIBRARIES AND Z3_EXECUTABLE)
  +# Searching for the version of the Z3 library is a best-effort task. The 
version
  +# is only recently added to a public header.
  +unset(Z3_VERSION_STRING)
  +
  +if(Z3_INCLUDE_DIR AND EXISTS "${Z3_INCLUDE_DIR}/z3_version.h")
  +# Z3 4.8.1+ has the version is in a public header.
  +file(STRINGS "${Z3_INCLUDE_DIR}/z3_version.h"
  + z3_version_str REGEX "^#define[\t ]+Z3_FULL_VERSION[\t ]+\".*\"")
  +
  +string(REGEX REPLACE "^.*Z3_FULL_VERSION[\t ]+\"Z3 ([0-9\.]+)\".*$" "\\1"
  + Z3_VERSION_STRING "${z3_version_str}")
  +unset(z3_version_str)
  +endif()
  +
  +if(NOT Z3_VERSION_STRING AND (Z3_INCLUDE_DIR AND Z3_LIBRARIES AND
  +  Z3_EXECUTABLE))
  +# Run the found z3 executable and parse the version string output.
   execute_process (COMMAND ${Z3_EXECUTABLE} -version
 OUTPUT_VARIABLE libz3_version_str
 ERROR_QUIET
  @@ -41,6 +57,20 @@ if(Z3_INCLUDE_DIR AND Z3_LIBRARIES AND Z3_EXECUTABLE)
   unset(libz3_version_str)
   endif()
   
  +if(NOT Z3_VERSION_STRING AND (Z3_INCLUDE_DIR AND Z3_LIBRARIES))
  +# We do not have the Z3 binary to query for a version. Try to use
  +# a small C++ program to detect it via the Z3_get_version() API call.
  +# TODO: add code from Mikhail Ramalho to obtain the version.
  +# TODO: set(Z3_VERSION_STRING) if successful.
  +endif()
  +
  +if(NOT Z3_VERSION_STRING)
  +# Give up: we are unable to obtain a version of the Z3 library. Be
  +# conservative and force the found version to 0.0.0 to make version
  +# checks always fail.
  +set(Z3_VERSION_STRING "0.0.0")
  +endif()
  +


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

In D54978#1397354 , @ddcc wrote:

> In D54978#1397316 , @mikhail.ramalho 
> wrote:
>
> > I just sent the first prototype of the solution. All the magic happens 
> > inside the `CHECK_CXX_SOURCE_RUNS` call.
>
>
> I think hardcoding the version into the binary is too brittle. Instead, your 
> program can just print out the current z3 version (much like the current 
> execution of the z3 binary), and the remaining logic can remain in CMake, 
> with the fallbacks as suggested above by @brzycki.


I don't think there is a mechanism to do so easily within CMake. The 
`CHECK_CXX_SOURCE_RUNS` call only returns a boolean answer, not stdout. You 
have to use the underlying `try_run()` command along with `RUN_OUTPUT_VARIABLE` 
to obtain a given version. This interface seems less simple than the 
`CHECK_CXX_*` macros.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

In D54978#1396927 , @ddcc wrote:

> The old `version.h` header isn't externally exposed, only the newer 
> `z3_version.h` header starting with version 4.8.1. I built a copy of 4.7.1 
> from source, and I don't see it, so unfortunately I think the second check 
> for `version.h` is superfluous. Instead, I think it'd be ok to still query 
> the executable as the primary, then fallback to this header as the secondary?


Thanks @ddcc for checking on `version.h`, I meant to do so but got side-tracked 
with other items today.

I think your suggestion is a good compromise, possibly something like the 
following as pseudo-code:

  if z3_version.h:
use_regex_parsed_version
  
  if version_not_valid and z3_executable:
use_z3_execution output_version
  
  if version_not_valid z3_include_dir:
try_mikhail.ramalho_runtime_check
  
  if version_not_valid:
warning "Z3 is not installed correctly or too old to detect its version"
version = 0.0.0


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

In D54978#1395562 , @mikhail.ramalho 
wrote:

> Hi @brzycki, but isn't it exactly what we want? I mean, if we try to 
> cross-compile and it fails for any reason (non-native library, wrong 
> version), then Z3_FOUND shouldn't be set.


I'm not sure, cross-compilation is tricky to get right.

> I just finished a small patch that checks the version as a run-time property. 
> Please, let me know your thoughts.
>  If you agree with this approach I'll create a separate revision for it (it 
> seems to work on ubuntu and fedora for me).

I'd be interested in seeing it and I'll happily provide feedback. I'm not sure 
if this method is better or worse than regex parsing of headers that @ddcc 
suggested.

No matter what algorithm chosen I'd strongly prefer the case when we are unable 
to ascertain the correct `Z3_VERSION_STRING` we should conservatively set this 
to `"0.0.0"` with a warning to inform the users early on something is strange 
with the version of Z3 being tested.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

> perhaps something like this:
> 
>   if(Z3_INCLUDE_DIR AND EXISTS "${Z3_INCLUDE_DIR }/z3_version.h")
> file(STRINGS "${Z3_INCLUDE_DIR }/z3_version.h" z3_version_str REGEX 
> "^#define[\t ]+Z3_FULL_VERSION[\t ]+\".*\"")
>   
> string(REGEX REPLACE "^.*Z3_FULL_VERSION[\t ]+\"Z3 ([0-9\.]+)\".*$" "\\1" 
> Z3_VERSION_STRING "${z3_version_str}")
> unset(z3_version_str)
>   endif()

That is almost exactly what I was thinking about this morning. I'd prefer the 
following since it's more robust for older versions:

  if(Z3_INCLUDE_DIR AND EXISTS "${Z3_INCLUDE_DIR }/z3_version.h")
# For 4.8.0 or newer
file(STRINGS "${Z3_INCLUDE_DIR }/z3_version.h" z3_version_str REGEX 
"^#define[\t ]+Z3_FULL_VERSION[\t ]+\".*\"")
  
string(REGEX REPLACE "^.*Z3_FULL_VERSION[\t ]+\"Z3 ([0-9\.]+)\".*$" "\\1" 
Z3_VERSION_STRING "${z3_version_str}")
unset(z3_version_str)
  elseif(Z3_INCLUDE_DIR AND EXISTS "${Z3_INCLUDE_DIR }/version.h")
file(STRINGS "${Z3_INCLUDE_DIR }/version.h" z3_version_str REGEX 
"^#define[\t ]+Z3_FULL_VERSION[\t ]+\".*\"")
  
string(REGEX REPLACE "^.*Z3_FULL_VERSION[\t ]+\"Z3 ([0-9\.]+)\".*$" "\\1" 
Z3_VERSION_STRING "${z3_version_str}")
unset(z3_version_str)
  else()
message(WARNING "Unable to locate the Z3 version.h header. Setting the 
found version to 0.0.0.")
set(Z3_VERSION_STRING "0.0.0")
  endif()


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

In D54978#1395476 , @mikhail.ramalho 
wrote:

> I'm wondering if we can remove the binary requirement all together: is it 
> possible to run a small program that would return EXIT_SUCCESS if the library 
> is the correct version?


Hi @mikhail.ramalho, I don't think this is feasible unfortunately. If we're 
using a cross-compiler the emitted binary won't be native to the platform. In 
other words, you cannot test for Z3 as a run-time property.

I looked at the Z3 source and they do have a `z3_version.h` file now and was 
added in version 4.4.2.0. You may be able to use the header directly, but I'm 
not sure how `find_package()` parses for library versions and if this is useful 
or not.  The generated header is named `src/util/version.h` in this initial 
commit:
https://github.com/Z3Prover/z3/commit/251527603df01904f70ed884f8695fedab5caed9

and was renamed last September to `src/util/z3_version.h` in this commit:
https://github.com/Z3Prover/z3/commit/0c4754d94bdfaf07077120f5cbff780d8fb0971d


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

In D54978#1395288 , @ddcc wrote:

> In D54978#1395268 , @brzycki wrote:
>
> > I think I found why others are struggling to recreate this issue. I did not 
> > have the package `z3/bionic` installed. This provides the `/usr/bin/z3` 
> > executable which `llvm/cmake/modules/FindZ3.cmake` relies upon to determine 
> > the correct `Z3_VERSION_STRING`.
>
>
> Yeah, that's what I meant by best-effort only. Due to upstream Z3's design, 
> without the binary, there is no easy way to retrieve the current installed 
> version, so when I originally wrote the Z3 integration, it seemed fine to let 
> the version check pass. Given the issues that have come up, it might make 
> more sense to at least emit a warning, or explicitly fail if the version 
> can't be determined, and prompt the user to install the binary.


Hello @ddcc.
I agree with your reasoning here and developed a patch based on this line of 
thought:

  diff --git a/llvm/cmake/modules/FindZ3.cmake b/llvm/cmake/modules/FindZ3.cmake
  index 5c6d3f0b427..b213342df37 100644
  --- a/llvm/cmake/modules/FindZ3.cmake
  +++ b/llvm/cmake/modules/FindZ3.cmake
  @@ -39,6 +39,11 @@ if(Z3_INCLUDE_DIR AND Z3_LIBRARIES AND Z3_EXECUTABLE)
   string(REGEX REPLACE "^Z3 version ([0-9.]+)" "\\1"
  Z3_VERSION_STRING "${libz3_version_str}")
   unset(libz3_version_str)
  +else()
  +# The version could not be determined from running Z3_EXECUTABLE. Set the
  +# version Z3 to the lowest possible value such that all checks for a
  +# minimum version will fail.
  +set(Z3_VERSION_STRING "0.0.0")
   endif()
  
   # handle the QUIETLY and REQUIRED arguments and set Z3_FOUND to TRUE if

This works for everything I could throw at it. If you think it's reasonable I 
can open another ticket and have the code reviewed as a separate fix.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

I think I found why others are struggling to recreate this issue. I did not 
have the package `z3/bionic` installed. This provides the `/usr/bin/z3` 
executable which `llvm/cmake/modules/FindZ3.cmake` relies upon to determine the 
correct `Z3_VERSION_STRING`.

If I perform the following on an unpatched checkout of sha b0a227049fda 
 the build 
works :

  sudo apt install -y z3 libz3-4 libz3-dev
  mkdir build && cd build

Either of the following CMake commands build successfully:

  cmake -G Ninja -D LLVM_OPTIMIZED_TABLEGEN=ON ../llvm-project/llvm
  cmake -G Ninja -D LLVM_OPTIMIZED_TABLEGEN=ON -D LLVM_ENABLE_Z3_SOLVER=OFF 
../llvm-project/llvm

And if I try `-D LLVM_ENABLE_Z3_SOLVER=ON` I receive a top-leve CMake error 
immediately:

  -- Could NOT find Z3: Found unsuitable version "4.4.1", but required is at 
least "4.7.1" (found /usr/lib/x86_64-linux-gnu/libz3.so)
  CMake Error at CMakeLists.txt:406 (message):
LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3 is not available.
  
  
  -- Configuring incomplete, errors occurred!
  See also "/work/brzycki/build/CMakeFiles/CMakeOutput.log".
  ninja: error: loading 'build.ninja': No such file or directory

Unfortunately it's completely valid to install packages `libz3-4` and 
`libz3-dev` without pulling in `z3` on Ubuntu 18.04.  I've added this to my 
internal build notes.

I'm also looking to see if there's a way to better  handle this case inside the 
`find_package(Z3 ...)` subsystem of llvm.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

The following patch:

  diff --git a/llvm/cmake/modules/CrossCompile.cmake 
b/llvm/cmake/modules/CrossCompile.cmake
  index bc3b210f018..0c30b88f80f 100644
  --- a/llvm/cmake/modules/CrossCompile.cmake
  +++ b/llvm/cmake/modules/CrossCompile.cmake
  @@ -53,6 +53,7 @@ function(llvm_create_cross_target_internal target_name 
toolchain buildtype)
   -DLLVM_DEFAULT_TARGET_TRIPLE="${TARGET_TRIPLE}"
   -DLLVM_TARGET_ARCH="${LLVM_TARGET_ARCH}"
   
-DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN="${LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN}"
  +-DLLVM_ENABLE_Z3_SOLVER="${LLVM_ENABLE_Z3_SOLVER}"
   ${build_type_flags} ${linker_flag} ${external_clang_dir}
   WORKING_DIRECTORY ${LLVM_${target_name}_BUILD}
   DEPENDS CREATE_LLVM_${target_name}

fixes the build break when CMake is called in the following manner:

  cmake -v -G Ninja  -D LLVM_OPTIMIZED_TABLEGEN=ON -D LLVM_ENABLE_Z3_SOLVER=OFF 
../llvm-project/llvm

However, the custom command sub-call to CMake always fails in the same way with 
either of these invocations:

  cmake -v -G Ninja  -D LLVM_OPTIMIZED_TABLEGEN=ON -D LLVM_ENABLE_Z3_SOLVER=ON 
../llvm-project/llvm
  cmake -v -G Ninja  -D LLVM_OPTIMIZED_TABLEGEN=ON ../llvm-project/llvm

The error is the following:

  [209/2543] /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Iutils/TableGen -I/work/brzycki/llvm-project/llvm/utils/TableGen 
-I/usr/include/libxml2 -Iinclude -I/work/brzycki/llvm-project/llvm/include 
-fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough 
-Wno-maybe-uninitialized -Wno-noexcept-type -Wdelete-non-virtual-dtor 
-Wno-comment -fdiagnostics-color -g-fno-exceptions -fno-rtti -MD -MT 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/GlobalISelEmitter.cpp.o -MF 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/GlobalISelEmitter.cpp.o.d -o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/GlobalISelEmitter.cpp.o -c 
/work/brzycki/llvm-project/llvm/utils/TableGen/GlobalISelEmitter.cpp
  [210/2543] cd /work/brzycki/build/NATIVE && 
/sarc-c/compiler_tmp/tools/build/cmake-3.13.3/bin/cmake -G Ninja 
-DCMAKE_MAKE_PROGRAM="/sarc-c/compiler_tmp/tools/build/ninja-1.8.2/ninja" 
-DCMAKE_C_COMPILER=/usr/bin/cc -DCMAKE_CXX_COMPILER=/usr/bin/c++ 
/work/brzycki/llvm-project/llvm -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE 
-DLLVM_TARGETS_TO_BUILD="AArch64;AMDGPU;ARM;BPF;Hexagon;Lanai;Mips;MSP430;NVPTX;PowerPC;Sparc;SystemZ;WebAssembly;X86;XCore"
 -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="" 
-DLLVM_DEFAULT_TARGET_TRIPLE="x86_64-unknown-linux-gnu" 
-DLLVM_TARGET_ARCH="host" -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN="OFF" 
-DLLVM_ENABLE_Z3_SOLVER="ON" -DCMAKE_BUILD_TYPE=Release
  -- The C compiler identification is GNU 7.3.0
  -- The CXX compiler identification is GNU 7.3.0
  -- The ASM compiler identification is GNU
  -- Found assembler: /usr/bin/cc
  ...
  ...
  -- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
  -- Performing Test HAVE_POSIX_REGEX
  -- Performing Test HAVE_POSIX_REGEX
  -- Performing Test HAVE_POSIX_REGEX -- success
  -- Performing Test HAVE_STEADY_CLOCK
  -- Performing Test HAVE_STEADY_CLOCK
  -- Performing Test HAVE_STEADY_CLOCK -- success
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /work/brzycki/build/NATIVE
  ninja: build stopped: subcommand failed.

I tried passing more information to the sub CMake call, but it yielded the 
exact same results:

  +-DLLVM_ENABLE_Z3_SOLVER="${LLVM_ENABLE_Z3_SOLVER}"
  +-DLLVM_Z3_INSTALL_DIR="${LLVM_Z3_INSTALL_DIR}"
  +-DZ3_EXECUTABLE="${Z3_EXECUTABLE}"
  +-DZ3_INCLUDE_DIR="${Z3_INCLUDE_DIR}"
  +-DZ3_LIBRARIES="${Z3_LIBRARIES}"

When I diff the successful sub-CMake with the failing one, the only difference 
is the detection of the Z3 solver library:

  $ diff -u good_submake.txt bad_submake.txt
  --- good_submake.txt2019-02-12 11:41:54.638892191 -0600
  +++ bad_submake.txt 2019-02-12 11:43:30.096484824 -0600
  @@ -14,7 +14,7 @@
   -- Detecting CXX compiler ABI info - done
   -- Detecting CXX compile features
   -- Detecting CXX compile features - done
  --- Could NOT find Z3 (missing: Z3_LIBRARIES Z3_INCLUDE_DIR) (Required is at 
least version "4.7.1")
  +-- Found Z3: /usr/lib/x86_64-linux-gnu/libz3.so (Required is at least 
version "4.7.1")
   -- Looking for dlfcn.h
   -- Looking for dlfcn.h - found
   -- Looking for errno.h


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

In D54978#1394613 , @thakis wrote:

> Got it now, sorry about being dense.


No problem, I appreciate you looking into this. :)

I hope to have some time in the next few days to help out and debug this 
further.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

In D54978#1393968 , @thakis wrote:

> Do you understand why the default matters for you? You seem to explicitly 
> disable the setting, and you still get Z3 as part of your build. Did you make 
> a clean build dir before turning it to OFF?


Yes, Please see my recreation instructions above. I created a new, empty 
`build` directory.

> If so, I don't understand why the default setting is important to you and why 
> this doesn't work for you. (I don't disagree with the default being off, I'm 
> just confused why things don't work for you.)

As I have stated several times, the CMake option `-D 
LLVM_OPTIMIZED_TABLEGEN=ON` spawns a sub-command of CMake and **is required for 
the break to occur**. I don't know how to make this any more clear. If you 
build with optimized tablegen, it breaks. I strongly suspect an interaction 
between LLVM's top-level CMake and the TableGen one but I haven't had time to 
debug it down to the exact cause.

It is important to me because the detection of the correct version of Z3 is 
imprecise, at best.  If a Z3 library is found  I have no way to guarantee a 
build I run will not attempt to include the library.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

In D54978#1392464 , @Szelethus wrote:

> Shouldn't that be off by default?


The default for `LLVM_ENABLE_Z3_SOLVER` depends entirely on what CMake detects 
from `find_package()`. Here is the relevant code in `llvm/CMakeLists.txt`:

  find_package(Z3 4.7.1)
  ...
  set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
  
  option(LLVM_ENABLE_Z3_SOLVER
"Enable Support for the Z3 constraint solver in LLVM."
${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
  )

If `find_package()` idenfiies a suitable `Z3_FOUND` the default is to enable 
builds with the Z3 framework. In other words the entire Z3 feature is manual 
opt-out and implicit opt-in when CMake thinks a suitable Z3 library is found.

In D54978#1393552 , @ddcc wrote:

> The likely reason for this versioning problem is that the current versioning 
> implementation in FindZ3.cmake is best-effort only.


Thank you @ddcc for this explanation. If that's the case I'd really prefer if 
`LLVM_ENABLE_Z3_SOLVER` was explicit opt-in and defaulted to `OFF` regardless 
of what `find_package` returned.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

> @brzycki, I can't reproduce your error. Maybe you're missing 
> `-DLLVM_ENABLE_Z3_SOLVER=OFF`?

Hello @mikhail.ramalho, here are my exact reproduction steps. I just verified 
them about 5 minutes ago.

  # Setup Ubuntu's Z3
  lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 18.04.1 LTS
  Release:18.04
  Codename:   bionic
  
  sudo apt install -y libz3-4 libz3-dev
  
  # Clone llvm-project and checkout the test SHA
  tmpd=$(mktemp -d)
  cd $tmpd
  git clone https://github.com/llvm/llvm-project.git
  git checkout b0a227049fda
  
  # Setup symlinks under llvm to compile correctly
  cd $tmpd/llvm-project/llvm
  ln -s ../../clang
  ln -s ../../polly
  ln -s ../../libcxx
  ln -s ../../libcxxabi
  
  # CMake and Ninja
  mkdir $tmpd/build
  cd $tmpd/build
  cmake -G Ninja -D LLVM_OPTIMIZED_TABLEGEN=ON -D LLVM_ENABLE_Z3_SOLVER=OFF 
../llvm-project/llvm
  ninja -v

These steps produce the error:

  [70/187] Building CXX object 
lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o
  FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o
  /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support 
-I/work/brzycki/llvm-project/llvm/lib/Support -I/usr/include/libxml2 -Iinclude 
-I/work/brzycki/llvm-project/llvm/include -fPIC -fvisibility-inlines-hidden 
-Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized 
-Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color 
-ffunction-sections -fdata-sections -O3 -DNDEBUG-fno-exceptions -fno-rtti 
-MD -MT lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o -MF 
lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o.d -o 
lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o -c 
/work/brzycki/llvm-project/llvm/lib/Support/Z3Solver.cpp
  /work/brzycki/llvm-project/llvm/lib/Support/Z3Solver.cpp: In function ‘void 
{anonymous}::Z3ErrorHandler(Z3_context, Z3_error_code)’:
  /work/brzycki/llvm-project/llvm/lib/Support/Z3Solver.cpp:44:71: error: cannot 
convert ‘Z3_context {aka _Z3_context*}’ to ‘Z3_error_code’ for argument ‘1’ to 
‘const char* Z3_get_error_msg(Z3_error_code)’
  llvm::Twine(Z3_get_error_msg(Context, Error)));
 ^

If I remove `-D LLVM_ENABLE_Z3_SOLVER=OFF` the actual TableGen CMake fails to 
succeed:

  cmake -G Ninja -D LLVM_OPTIMIZED_TABLEGEN=ON ../llvm-project/llvm
  ninja -v

And here's the TableGen CMake error:

  [218/3618] cd /work/brzycki/build/NATIVE && 
/sarc-c/compiler_tmp/tools/build/cmake-3.13.3/bin/cmake -G Ninja 
-DCMAKE_MAKE_PROGRAM="/sarc-c/compiler_tmp/tools/build/ninja-1.8.2/ninja" 
-DCMAKE_C_COMPILER=/usr/bin/cc -DCMAKE_CXX_COMPILER=/usr/bin/c++ 
/work/brzycki/llvm-project/llvm -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE 
-DLLVM_TARGETS_TO_BUILD="AArch64;AMDGPU;ARM;BPF;Hexagon;Lanai;Mips;MSP430;NVPTX;PowerPC;Sparc;SystemZ;WebAssembly;X86;XCore"
 -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="" 
-DLLVM_DEFAULT_TARGET_TRIPLE="x86_64-unknown-linux-gnu" 
-DLLVM_TARGET_ARCH="host" -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN="OFF" 
-DCMAKE_BUILD_TYPE=Release
  -- The C compiler identification is GNU 7.3.0
  -- The CXX compiler identification is GNU 7.3.0
  -- The ASM compiler identification is GNU
  -- Found assembler: /usr/bin/cc
  -- Check for working C compiler: /usr/bin/cc
  -- Check for working C compiler: /usr/bin/cc -- works
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- Check for working CXX compiler: /usr/bin/c++
  -- Check for working CXX compiler: /usr/bin/c++ -- works
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Found Z3: /usr/lib/x86_64-linux-gnu/libz3.so (Required is at least version 
"4.7.1")
  -- Looking for dlfcn.h
  -- Looking for dlfcn.h - found
  -- Looking for errno.h
  -- Looking for errno.h - found
  -- Looking for fcntl.h
  -- Looking for fcntl.h - found
  -- Looking for link.h
  -- Looking for link.h - found
  -- Looking for malloc/malloc.h
  -- Looking for malloc/malloc.h - not found
  -- Looking for pthread.h
  -- Looking for pthread.h - found
  -- Looking for signal.h
  -- Looking for signal.h - found
  -- Looking for sys/ioctl.h
  -- Looking for sys/ioctl.h - found
  -- Looking for sys/mman.h
  -- Looking for sys/mman.h - found
  -- Looking for sys/param.h
  -- Looking for sys/param.h - found
  -- Looking for sys/resource.h
  -- Looking for sys/resource.h - found
  -- Looking for sys/stat.h
  -- Looking for sys/stat.h - found
  -- Looking for sys/time.h
  -- Looking for sys/time.h - 

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

In D54978#1390698 , @thakis wrote:

> Thanks for the analysis. I think it's fine if you revert, given that.


I'm running in to conflict dependency issues when attempting to revert rL353373 
. There is at least one other conflicting 
commit rL353465  on top of this code already.

I don't feel comfortable reverting 2+ patches in a sub-section of the code I 
know little about on a Friday afternoon. :)


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

> From what I understand, setting `-DLLVM_ENABLE_Z3_SOLVER=OFF` is supposed to 
> work

Hello @thakis, I have reduced it down to the minimal required flags on Ubuntu 
18.04. I ran this on llvm-project SHA b0a227049fda9d0d229ea801ae77bf1b812f7328 
 from Feb 
8, 2019.

First, make sure Ubuntu has installed its version of Z3:

  sudo apt install libz3-4 libz3-dev
  dpkg -l | grep libz3
  ii  libz3-4:amd64 4.4.1-0.3build4 
amd64theorem prover from Microsoft Research - runtime libraries
  ii  libz3-dev:amd64   4.4.1-0.3build4 
amd64theorem prover from Microsoft Research - development files

Next, run CMake with the following arguments:

  mkdir build && cd build
  cmake \
-G Ninja \
-D LLVM_OPTIMIZED_TABLEGEN=ON \
-D LLVM_ENABLE_Z3_SOLVER=OFF \
  /path/to/llvm-project/llvm

First, you'll see that CMake detects a version of Z3:

  -- Found Z3: /usr/lib/x86_64-linux-gnu/libz3.so (Required is at least version 
"4.7.1")

At around ninja command 600-700 a second CMake instance is spawned for the 
TableGen optimizations:

  [666/3618] cd /work/brzycki/b/NATIVE && 
/sarc-c/compiler_tmp/tools/build/cmake-3.13.3/bin/cmake -G Ninja 
-DCMAKE_MAKE_PROGRAM="/sarc-c/compiler_tmp/tools/build/ninja-1.8.2/ninja" 
-DCMAKE_C_COMPILER=/usr/bin/cc -DCMAKE_CXX_COMPILER=/usr/bin/c++ 
/work/brzycki/llvm-project/llvm -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE 
-DLLVM_TARGETS_TO_BUILD="AArch64;AMDGPU;ARM;BPF;Hexagon;Lanai;Mips;MSP430;NVPTX;PowerPC;Sparc;SystemZ;WebAssembly;X86;XCore"
 -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="" 
-DLLVM_DEFAULT_TARGET_TRIPLE="x86_64-unknown-linux-gnu" 
-DLLVM_TARGET_ARCH="host" -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN="OFF" 
-DCMAKE_BUILD_TYPE=Release
  -- The C compiler identification is GNU 7.3.0
  -- The CXX compiler identification is GNU 7.3.0
  -- The ASM compiler identification is GNU
  -- Found assembler: /usr/bin/cc
  -- Check for working C compiler: /usr/bin/cc
  -- Check for working C compiler: /usr/bin/cc -- works
  ...

And shortly after that we fail:

  -- Build files have been written to: /work/brzycki/b/NATIVE
  [666/3618] cd /work/brzycki/b/NATIVE && 
/sarc-c/compiler_tmp/tools/build/cmake-3.13.3/bin/cmake --build 
/work/brzycki/b/NATIVE --target llvm-tblgen --config Release
  [72/187] Building CXX object 
lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o
  FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o
  /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support 
-I/work/brzycki/llvm-project/llvm/lib/Support -I/usr/include/libxml2 -Iinclude 
-I/work/brzycki/llvm-project/llvm/include -fPIC -fvisibility-inlines-hidden 
-Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized 
-Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color 
-ffunction-sections -fdata-sections -O3 -DNDEBUG-fno-exceptions -fno-rtti 
-MD -MT lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o -MF 
lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o.d -o 
lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o -c 
/work/brzycki/llvm-project/llvm/lib/Support/Z3Solver.cpp
  /work/brzycki/llvm-project/llvm/lib/Support/Z3Solver.cpp: In function ‘void 
{anonymous}::Z3ErrorHandler(Z3_context, Z3_error_code)’:
  /work/brzycki/llvm-project/llvm/lib/Support/Z3Solver.cpp:44:71: error: cannot 
convert ‘Z3_context {aka _Z3_context* ’ to ‘Z3_error_code’ for argument ‘1’ to 
‘const char* Z3_get_error_msg(Z3_error_code)’
  llvm::Twine(Z3_get_error_msg(Context, Error)));
 ^
  [183/187] Building CXX object 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/GlobalISelEmitter.cpp.o
  ninja: build stopped: subcommand failed.
  FAILED: NATIVE/bin/llvm-tblgen
  cd /work/brzycki/b/NATIVE && 
/sarc-c/compiler_tmp/tools/build/cmake-3.13.3/bin/cmake --build 
/work/brzycki/b/NATIVE --target llvm-tblgen --config Release
  ninja: build stopped: subcommand failed.

I consider this to be 2 bugs:

1. CMake should not set Z3_FOUND when the library is too old. The 
llvm/CMakeLists.txt file correctly states `find_package(Z3 4.7.1)` but it 
doesn't work right and consideres the 4.4.1 one valid. It's why I'm in this 
mess in the first place.
2. There's some sort of interaction bug between the top-level 
llvm/CMakeLists.txt and the tablegen one when optimizations are turned on. It 
doesn't seem to respect the `LLVM_ENABLE_Z3_SOLVER` directive.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978

[PATCH] D54978: Move the SMT API to LLVM

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

This commit is causing a build-break for our nightly cross compilers of arm and 
aarch64. The immediately preceding commit of D54977 
 does not break with the exact same invocation.

The problem is our build machine (Ubuntu 18.04 LTS) installs an old version of 
Z3 that is incompatible with LLVM's tip of tree. To deal with this we add `-D 
CLANG_ANALYZER_ENABLE_Z3_SOLVER=OFF` to force disabling Z3 even if CMake 
detects the library is installed.

With this patch I am unable to disable Z3 because 
`CLANG_ANALYZER_ENABLE_Z3_SOLVER` is no longer in the codebase and setting `-D 
LLVM_ENABLE_Z3_SOLVER=OFF` still builds Z3 support (which fails):

  [74/187] Building CXX object 
lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o
  FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o
  /usr/bin/clang++-6.0  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Ilib/Support -I/tmp/tmp.UCDOJjmgJ1/src/llvm/lib/Support -I/usr/include/libxml2 
-Iinclude -I/tmp/tmp.UCDOJjmgJ1/src/llvm/include -fPIC 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -std=c++11 -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
-pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default 
-Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
-Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -O3 
-DNDEBUG-fno-exceptions -fno-rtti -MD -MT 
lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o -MF 
lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o.d -o 
lib/Support/CMakeFiles/LLVMSupport.dir/Z3Solver.cpp.o -c 
/tmp/tmp.UCDOJjmgJ1/src/llvm/lib/Support/Z3Solver.cpp
  /tmp/tmp.UCDOJjmgJ1/src/llvm/lib/Support/Z3Solver.cpp:44:40: error: no 
matching function for call to 'Z3_get_error_msg'
 llvm::Twine(Z3_get_error_msg(Context, Error)));
 ^~~~


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54978/new/

https://reviews.llvm.org/D54978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits