41da8b1e9a
Fixes #10303. ## Symptom On the reported QF_NRA instance z3 answers `sat` for some values of `smt.random_seed` and `unsat` for others, and every `sat` comes with a model z3's own validator rejects. The correct answer is `unsat`. `smt.arith.solver=2` is unaffected; `smt.arith.solver=6` (the default) is not. ## Root cause The simplex model is not rational — each column is a `numeric_pair<mpq>` `(x, y)` denoting `x + δ·y`, where `δ` is a positive infinitesimal used to represent *strict* bounds exactly (`v > 0` is stored as `(0, 1)`). `δ` only becomes concrete at model-output time, in `from_model_in_impq_to_mpq(v) = v.x + m_delta * v.y`. But nla decides monomial consistency using **only the rational parts**: ```cpp const rational& val(lpvar j) const { return lra.get_column_value(j).x; } // nla_core.h:165 r *= lra.get_column_value(j).x; // product_value return product_value(m) == lra.get_column_value(m.var()).x; // check_monic ``` That is sound only on a δ-free model, and it cannot be repaired by also tracking `y`: a **product** `(x₁+δy₁)(x₂+δy₂)` has a `δ²` term, which a `numeric_pair` cannot represent. The delta encoding is inherently linear, so nla structurally cannot reason on a δ-carrying model. The code relies on this: `core::check()` calls `lra.get_rid_of_inf_eps()` as its very first action to instantiate δ before any monomial is inspected. The invariant is: > `m_to_refine` must only ever be computed on a δ-free model. `core::optimize_nl_bounds()` breaks it. It calls `lra.find_feasible_solution()` in the middle of the nla check; the simplex re-runs, parks columns back onto strict bounds and **re-introduces non-zero `y`**. It then calls `init_to_refine()` on that model — one full LP re-solve after the scrub in `core::check()`. A wrong `m_to_refine` turns directly into a wrong answer: ``` find_feasible_solution() re-introduces δ → init_to_refine() mis-measures monomials (compares only .x) → m_to_refine wrongly empty → horner.cpp:117 set_nla_satisfied() → core::check() returns l_true → theory_lra FC_DONE → sat → model output instantiates δ (x + m_delta·y) → monomial equations violated → "an invalid model was generated" ``` Instrumenting model construction on the reported benchmark confirms it exactly: `use_nra_model=0`, **87 columns still carrying infinitesimals, 44 monomials violated** once δ is instantiated — every one of them with `to_refine = 0`. ## Fix Enforce the invariant where it is actually depended upon, instead of only at the entry to `core::check()`: ```cpp void core::init_to_refine() { if (lra.is_feasible()) lra.get_rid_of_inf_eps(); m_to_refine.reset(); ... } ``` Every caller — including the ones inside `optimize_nl_bounds()` that follow an LP re-solve — now measures monomials on a δ-free model. A second commit closes a related hole: the `arith.nl.optimize_bounds_lp_max_vars` throttle exit returns *after* `find_feasible_solution()` has already moved the model, and was the only exit that never called `init_to_refine()` at all — leaving `m_to_refine` stale rather than merely δ-contaminated. ## Validation Reported benchmark, `tactic.default_tactic=smt` (deterministic — the default QF_NRA portfolio uses wall-clock `try_for` budgets, so it is timing-dependent): master fails on **9 of 20** seeds; with the fix **20/20** answer `unsat`. Under the default configuration, seeds 1–10 all answer `unsat` (was `sat` + invalid model on 1, 3, 4, 10), matching `smt.arith.solver=2`. The bug was much broader than the single reported instance. On the `QF_NRA_small` corpus (1147 instances, `-T:10`): | | sat | unsat | unknown | invalid model | |---|---|---|---|---| | master | 460 | 597 | 77 | **13** | | this PR | 466 | 602 | 79 | **0** | **Zero sat/unsat conflicts.** Of the 13 instances where master emitted an invalid model, **7 are genuinely `unsat`** — the same unsoundness as the reported one. ## Performance Net **faster**, on the 1054 instances answered identically before and after: | | total | |---|---| | master | 229.7 s | | this PR | 146.4 s (**−36.3 %**) | 133 instances faster by >200 ms vs. 13 slower by >200 ms. The added `get_rid_of_inf_eps()` is asymptotically free — `init_to_refine()` already costs Θ(Σ|monic|) arbitrary-precision *multiplications*, so adding Θ(#columns) `mpq::is_zero()` tests (which early-exit when no deltas are present) does not change its complexity class. The expensive path is also moved rather than added: deltas left by `optimize_nl_bounds()` previously survived until the next `core::check()`, which paid the full `find_delta_for_strict_bounds` + rewrite cost anyway. The speedup itself comes from correctness — a truthful `m_to_refine` points grobner / basic_lemma / order / monotonicity / tangent / nra at the monomials that are genuinely violated, instead of letting them chase a model that was never consistent. `test-z3 /a`: 93/93 pass. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|---|---|---|
| .github | ||
| a3 | ||
| cmake | ||
| codeql/custom_queries | ||
| contrib | ||
| doc | ||
| docker | ||
| examples | ||
| noarch | ||
| resources | ||
| scripts | ||
| src | ||
| .bazelrc | ||
| .clang-format | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| BUILD.bazel | ||
| build_z3.bat | ||
| CMakeLists.txt | ||
| configure | ||
| LICENSE.txt | ||
| MODULE.bazel | ||
| README-CMake.md | ||
| README.md | ||
| RELEASE_NOTES.md | ||
| Z3-AGENT.md | ||
| z3.log | ||
| z3.pc.cmake.in | ||
| z3guide.jpeg | ||
Z3
Z3 is a theorem prover from Microsoft Research. It is licensed under the MIT license. Windows binary distributions include C++ runtime redistributables
If you are not familiar with Z3, you can start here.
Pre-built binaries for stable and nightly releases are available here.
Z3 can be built using Visual Studio, a Makefile, using CMake, using vcpkg, or using Bazel. It provides bindings for several programming languages.
See the release notes for notes on various stable releases of Z3.
Build status
Pull Request & Push Workflows
| WASM Build | Windows Build | CI | OCaml Binding |
|---|---|---|---|
 |
 |
 |
 |
Scheduled Workflows
| Open Bugs | Android Build | Pyodide Wheel (PyPI) | Nightly Build | Cross Build | F* Master Build |
|---|---|---|---|---|---|
 |
 |
 |
 |
 |
 |
| MSVC Static | MSVC Clang-CL | Build Z3 Cache | Memory Safety | Mark PRs Ready |
|---|---|---|---|---|
 |
 |
 |
 |
 |
Manual & Release Workflows
| Documentation | Release Build | WASM Release |
|---|---|---|
 |
 |
 |
Specialized Workflows
| Nightly Validation | Copilot Setup | Agentics Maintenance |
|---|---|---|
 |
 |
 |
Agentic Workflows
| API Coherence | Code Simplifier | Release Notes | Workflow Suggestion | Academic Citation |
|---|---|---|---|---|
 |
 |
 |
 |
 |
| Issue Backlog | Memory Safety Report | Specbot Crash Analyzer | SMTLIB Benchmark Finder |
|---|---|---|---|
 |
 |
 |
 |
| TPTP Benchmark |
|---|
 |
Building Z3 on Windows using Visual Studio Command Prompt
For 32-bit builds, start with:
python scripts/mk_make.py
or instead, for a 64-bit build:
python scripts/mk_make.py -x
then run:
cd build
nmake
Z3 uses C++20. The recommended version of Visual Studio is therefore VS2019 or later.
Security Features (MSVC): When building with Visual Studio/MSVC, a couple of security features are enabled by default for Z3:
- Control Flow Guard (
/guard:cf) - enabled by default to detect attempts to compromise your code by preventing calls to locations other than function entry points, making it more difficult for attackers to execute arbitrary code through control flow redirection - Address Space Layout Randomization (
/DYNAMICBASE) - enabled by default for memory layout randomization, required by the/GUARD:CFlinker option - These can be disabled using
python scripts/mk_make.py --no-guardcf(Python build) orcmake -DZ3_ENABLE_CFG=OFF(CMake build) if needed
Building Z3 using make and GCC/Clang
Execute:
python scripts/mk_make.py
cd build
make
sudo make install
Note by default g++ is used as C++ compiler if it is available. If you
prefer to use Clang, change the mk_make.py invocation to:
CXX=clang++ CC=clang python scripts/mk_make.py
Note that Clang < 3.7 does not support OpenMP.
You can also build Z3 for Windows using Cygwin and the Mingw-w64 cross-compiler. In that case, make sure to use Cygwin's own Python and not some Windows installation of Python.
For a 64-bit build (from Cygwin64), configure Z3's sources with
CXX=x86_64-w64-mingw32-g++ CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-ar python scripts/mk_make.py
A 32-bit build should work similarly (but is untested); the same is true for 32/64 bit builds from within Cygwin32.
By default, it will install z3 executables at PREFIX/bin, libraries at
PREFIX/lib, and include files at PREFIX/include, where the PREFIX
installation prefix is inferred by the mk_make.py script. It is usually
/usr for most Linux distros, and /usr/local for FreeBSD and macOS. Use
the --prefix= command-line option to change the install prefix. For example:
python scripts/mk_make.py --prefix=/home/leo
cd build
make
make install
To uninstall Z3, use
sudo make uninstall
To clean Z3, you can delete the build directory and run the mk_make.py script again.
Building Z3 using CMake
Z3 has a build system using CMake. Read the README-CMake.md file for details. It is recommended for most build tasks, except for building OCaml bindings.
Building Z3 using vcpkg
vcpkg is a full platform package manager. To install Z3 with vcpkg, execute:
git clone https://github.com/microsoft/vcpkg.git
./bootstrap-vcpkg.bat # For powershell
./bootstrap-vcpkg.sh # For bash
./vcpkg install z3
Building Z3 using Bazel
Z3 can be built using Bazel. This is known to work on Ubuntu with Clang (but may work elsewhere with other compilers):
bazel build //...
Dependencies
Z3 itself has only few dependencies. It uses C++ runtime libraries, including pthreads for multi-threading. It is optionally possible to use GMP for multi-precision integers, but Z3 contains its own self-contained multi-precision functionality. Python is required to build Z3. Building Java, .NET, OCaml and Julia APIs requires installing relevant toolchains.
Z3 bindings
Z3 has bindings for various programming languages.
.NET
You can install a NuGet package for the latest release Z3 from nuget.org.
Use the --dotnet command line flag with mk_make.py to enable building these.
See examples/dotnet for examples.
C
These are always enabled.
See examples/c for examples.
C++
These are always enabled.
See examples/c++ for examples.
Java
Use the --java command line flag with mk_make.py to enable building these.
For IDE setup instructions (Eclipse, IntelliJ IDEA, Visual Studio Code) and troubleshooting, see the Java IDE Setup Guide.
See examples/java for examples.
Go
Use the --go command line flag with mk_make.py to enable building these. Note that Go bindings use CGO and require a Go toolchain (Go 1.20 or later) to build.
With CMake, use the -DZ3_BUILD_GO_BINDINGS=ON option.
See examples/go for examples and src/api/go/README.md for complete API documentation.
OCaml
Use the --ml command line flag with mk_make.py to enable building these.
See examples/ml for examples.
Python
You can install the Python wrapper for Z3 for the latest release from pypi using the command:
pip install z3-solver
Use the --python command line flag with mk_make.py to enable building these.
Note that it is required on certain platforms that the Python package directory
(site-packages on most distributions and dist-packages on Debian-based
distributions) live under the install prefix. If you use a non-standard prefix
you can use the --pypkgdir option to change the Python package directory
used for installation. For example:
python scripts/mk_make.py --prefix=/home/leo --python --pypkgdir=/home/leo/lib/python-2.7/site-packages
If you do need to install to a non-standard prefix, a better approach is to use
a Python virtual environment
and install Z3 there. Python packages also work for Python3.
Under Windows, recall to build inside the Visual C++ native command build environment.
Note that the build/python/z3 directory should be accessible from where Python is used with Z3
and it requires libz3.dll to be in the path.
virtualenv venv
source venv/bin/activate
python scripts/mk_make.py --python
cd build
make
make install
# You will find Z3 and the Python bindings installed in the virtual environment
venv/bin/z3 -h
...
python -c 'import z3; print(z3.get_version_string())'
...
See examples/python for examples.
Julia
The Julia package Z3.jl wraps the C API of Z3. A previous version of it wrapped the C++ API: Information about updating and building the Julia bindings can be found in src/api/julia.
WebAssembly / TypeScript / JavaScript
A WebAssembly build with associated TypeScript typings is published on npm as z3-solver. Information about building these bindings can be found in src/api/js.
Smalltalk (Pharo / Smalltalk/X)
Project MachineArithmetic provides a Smalltalk interface to Z3's C API. For more information, see MachineArithmetic/README.md.
AIX
Build settings for AIX are described here.
System Overview
Interfaces
-
Default input format is SMTLIB2
-
Other native foreign function interfaces:
-
Python API (also available in pydoc format)
-
C
-
OCaml
-
Smalltalk (supports Pharo and Smalltalk/X)
Power Tools
- The Axiom Profiler currently developed by ETH Zurich