3
0
Fork 0
mirror of https://github.com/Z3Prover/z3 synced 2026-08-09 23:42:21 +00:00
No description
Find a file
Margus Veanes 9866fee194
Live-state traversal and interval-refinement product for seq_monadic, minus the postponed prunes (#10455)
Rebases the `seq-live-states` work onto current `master`, drops the two
additions that are being postponed, and fixes a live-state ordering
regression
that the rebase exposed.

### What is in

1. **`63ad8f944` Add lazy regex live-state traversal** — moves
live-state
   computation out of `seq_monadic`/`seq_regex` into a shared
`seq::live_states` that interns derivative states, keeps a predecessor
graph, and marks liveness by backward propagation from nullable states.
The
reachable set is exposed as a lazy iterator instead of being
materialised.
2. **`42e82f3e8` Consume live states lazily in `dfs_atoms` (#10381)** —
makes
the only consumer actually lazy. It previously drained the iterator into
a
`ptr_vector` before exploring anything, so a root with an exponential
live
   set was paid for in full even when a witness appeared immediately.
3. **`d67bbfab6` Build the `seq_monadic` product from interval
refinement
(#10384)** — replaces the cartesian product over cofactor guards with a
   cursor merge over per-state ordered-interval forms.
4. **`e1b3dc9af`** — reconciles the state display with upstream #10431,
which
   started reading `m_live_cache` after this work had replaced it. Adds
   `live_states::num_states()`.
5. **`1fea78d5d` Emit the root first when enumerating live states** —
new here,
   see below.

### What is out

* **The Bloom-filter / `atom_sig` prune** (`f96e37753` on
`seq-live-states`) is
  dropped. It keys on syntactic features and is a maintenance liability.
* **The approximate semilinear length abstraction** is dropped. It is
worth
revisiting, but with a real semilinear representation for `∃k. k·SL(R)`
rather than the gcd approximation, and after surveying what the Parikh
solver
  already provides.

Neither is on `master`; nothing is being reverted from upstream.

### The ordering fix

Evaluating commits 1–4 against `master` initially looked bad: +2/−5
decided and
**+23.3%** time on commonly decided benchmarks. Bisecting over
per-commit
builds put four of the five losses on commit 1, and the cause is an
enumeration
order change.

`m_live_frontier` is appended in the order liveness is *discovered*,
which is
bottom-up — `mark_live` records a nullable state and then propagates
backwards
through predecessors. A root is rarely nullable itself, so it becomes
live only
by back-propagation and lands **last**. The eager traversal that was
removed
emitted states in interning order, i.e. **root first**. `dfs_atoms` uses
that
sequence as a search order and stops at the first `l_true`, so the root
moving
to the back reordered every split search, and four `split_membership`
benchmarks lost their witness-first branch.

`1fea78d5d` restores the root to index 0 and leaves the rest of the
frontier
order alone. This is deliberately narrower than restoring full interning
order,
which was prototyped in #10381 and rejected — that fixed the same
regressions
but lost `medium_sat_0003/0026/0036/0052` and cost 31% on
light-antimirov,
because per-state forward liveness is quadratic where backward
propagation is
linear. Moving only the root keeps both.

The remap is well defined: every state in a search is reachable from the
root,
so liveness reaches the root within the same `expand()` step, and
whenever the
frontier is non-empty at an `ensure()` boundary the root is already in
it. The
element count is unchanged, so `ensure`'s bound still holds.

### Results

ClemensRegex, 1178 benchmarks, 10s timeout,
`smt.seq.regex_monadic=true`,
against `master`:

| | commits 1–4 | + ordering fix |
|---|---|---|
| decided | +2 / −5 | **+6 / −1** |
| time, 1072 commonly decided | +23.3% | **−22.5%** (197.3s → 152.9s) |

No sat/unsat contradictions. 23 benchmarks ≥2x faster, 7 ≥2x slower.

| family | n | both | base | new | Δ |
|---|---|---|---|---|---|
| `Automatic/generated` | 80 | 17 | 29.6s | 11.4s | −61.3% |
| `Automatic/generated_easy` | 20 | 11 | 14.0s | 3.9s | −72.4% |
| `Automatic/generated_tiny` | 30 | 30 | 6.6s | 5.2s | −21.4% |
| `Manual/with_lengths` | 12 | 5 | 7.0s | 7.1s | +0.7% |
| `Manual/without_lengths` | 120 | 113 | 29.9s | 20.0s | −33.2% |
| `QF_S_extracted_with_equations` | 52 | 32 | 10.2s | 9.5s | −6.9% |
| `QF_S_extracted_without_equations` | 864 | 864 | 100.0s | 95.9s |
−4.1% |

Newly decided: `medium_sat_0026/0036/0038`, `easy_unsat_0007/0010/0011`.
Largest single gains are `medium_unsat_0027` (7.4s → 1.3s),
`medium_unsat_0058`
(6.6s → 1.4s) and `noodler_killer_11_symmetric_nth` (3.8s → 0.15s).

MargusRegex (298) is unchanged — 297/298 decided by both sides, no
verdict
differences. That corpus is startup-dominated at ~25ms per benchmark and
serves
as a correctness net rather than a performance signal.

`test-z3 seq_monadic` and `test-z3 seq_rewriter` pass.

### What the interval-refinement product contributes on its own

Since #10384 is the largest diff here, it was re-measured in isolation:
two
builds differing only in `d67bbfab6`, both with the ordering fix, so
nothing is
confounded. +2 decided, 0 lost, 0 contradictions, and the benefit scales
with
how solver-bound the goal is:

| baseline cost | n | base | new | speedup |
|---|---|---|---|---|
| <100 ms | 821 | 61.5s | 63.2s | 1.00x |
| 100–250 ms | 209 | 26.6s | 24.8s | 1.07x |
| 250 ms–1 s | 33 | 12.2s | 10.3s | 1.19x |
| 1–5 s | 11 | 25.5s | 16.0s | 1.59x |
| >5 s | 3 | 19.5s | 3.1s | 6.35x |
| **solver-bound (≥250 ms)** | **47** | **57.3s** | **29.4s** |
**1.95x** |

The +2.8% on sub-100ms files is measurement noise: median-of-3 repeat
runs over
a 150-file sample give −0.1%, so the per-state interval cache costs
nothing on
cheap goals.

Split by verdict it is sharper still — the refinement is an **unsat
accelerator and exactly neutral on sat**, which follows from the
mechanism:
unsat has to exhaust the product state space so cell enumeration is the
entire
cost, while sat short-circuits at the first witness.

| | n | base | new | speedup |
|---|---|---|---|---|
| sat | 903 | 89.3s | 89.3s | 1.00x |
| unsat | 174 | 56.1s | 28.1s | 1.99x |
| unsat, ≥250 ms | 24 | 43.0s | 15.1s | **2.84x** |

This corroborates the 2.05x/2.36x reported in #10384, and locates it:
~1.0x on
three quarters of the corpus, 2.8x on the two dozen files that dominate
runtime.

### Known regression

`split_membership_medium_unsat_0047` (1.0s → timeout) is not an ordering
problem; it regressed with commit 2 and the ordering fix does not touch
it.
`master` hits the live-state cap before exploring anything and hands
over to
the legacy fallback in 0.7s, which then decides it in three further
monadic
checks. The lazy loop instead explores the truncated frontier first, and
those
explorations build very large derivative terms — 96k cofactor calls take
20s
against 165k in 0.7s on `master`, at 82MB versus 18MB.

The node budget does not catch it because the cost is in term size, not
node
count. Bounding the speculative work by budget units was tried and
rejected: it
did not recover 0047 and it lost `medium_sat_0026`. Charging the budget
by term
size would likely fix it, but that is a broader change than belongs
here.

### Follow-up: the budget is now miscalibrated

Worth flagging because it makes the numbers above an understatement. The
DFS
budget is a hard 200,000 pops, calibrated when each pop was ~8x more
expensive.
`split_membership_easy_sat_0019` is the only ≥2x slowdown attributable
to the
interval product, and it is entirely this effect: at 200k the merge
build bails
on budget 25 times and falls back to legacy (3.6s, against 1.8s for the
cartesian build), while at 1,000,000 it returns in **0.17s after 131
cofactor
calls** with no bails. #10384 measured +5/+6 decided at the raised
budget. That
is a policy change affecting all users, so it belongs in its own PR.

---------

Co-authored-by: Nikolaj Bjorner <nbjorner@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: veanes <veanes@microsoft.com>
Copilot-Session: 2bcccba7-ac7d-476e-8dfe-718a21d37554
Copilot-Session: a2ce3573-4e15-4a4a-afb5-21e3cb04e4a2
2026-08-07 21:39:20 -07:00
.github Extend Ostrich benchmark workflow to include cvc5 and Ostrich2 (#10429) 2026-08-06 19:51:47 -07:00
a3 update a3-python to fix issues 2026-02-18 08:16:56 -08:00
cmake Fix uses of gnu anonymous structs. (#10345) 2026-08-01 11:44:01 -07:00
codeql/custom_queries add analysis 2025-09-28 13:02:05 +03:00
contrib tiny fix to qprofdiff (#6497) 2022-12-30 15:25:01 -08:00
doc Remove unnecessary blank lines in mk_genfile_common.py and mk_api_doc.py 2026-02-19 17:52:11 +00:00
docker Update docker-image.yml (#5739) 2021-12-25 17:33:35 -08:00
examples Remove tptp5 example 2026-07-29 14:01:08 -07:00
noarch
resources
scripts Load versioned libz3 soname in Python bindings on Linux (#10290) 2026-07-29 14:01:55 -07:00
src Live-state traversal and interval-refinement product for seq_monadic, minus the postponed prunes (#10455) 2026-08-07 21:39:20 -07:00
.bazelrc Expose z3_static target for Bazel build (#7660) 2025-06-03 11:51:18 +02:00
.clang-format update clang format 2025-10-02 10:39:37 -07:00
.dockerignore
.gitattributes Merge with branch lws (#8498) 2026-02-04 09:52:02 -08:00
.gitignore Derive with ranges (#9965) 2026-06-26 08:44:13 -06:00
BUILD.bazel fix(bazel): pin CMake library installs to lib (#10126) 2026-07-14 08:30:48 -07:00
build_z3.bat git bindings v1.0 2026-02-15 21:24:40 -08:00
CMakeLists.txt Fix MinGW linker errors: explicitly link dbghelp on Windows (#10203) 2026-07-23 10:25:58 -07:00
configure
LICENSE.txt
MODULE.bazel update version 2026-07-16 15:39:15 -07:00
README-CMake.md [CMake] Guard Z3_API_LOG_SYNC against Z3_SINGLE_THREADED (#10088) 2026-07-11 19:20:15 -07:00
README.md Add F* master workflow badge to README build ribbons (#10279) 2026-07-28 11:53:53 -07:00
RELEASE_NOTES.md update release notes 2026-07-16 15:39:57 -07:00
Z3-AGENT.md add per-skill @z3 usage examples to agent readme 2026-03-12 00:16:06 +00:00
z3.log Fix releaseClang segfault: declare invoke_exit_action [[noreturn]], remove __builtin_unreachable() from UNREACHABLE() (#10295) 2026-07-29 13:23:43 -07:00
z3.pc.cmake.in Fix z3.pc file template (#4693) 2020-09-18 12:39:12 -07:00
z3guide.jpeg add picture of z3guide 2024-11-18 13:21:35 -08:00

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.

Try the online Z3 Guide

Build status

Pull Request & Push Workflows

WASM Build Windows Build CI OCaml Binding
WASM Build Windows CI OCaml Binding CI

Scheduled Workflows

Open Bugs Android Build Pyodide Wheel (PyPI) Nightly Build Cross Build F* Master Build
Open Issues Android Build Pyodide Wheel (PyPI) Nightly Build RISC V and PowerPC 64 F* Master Build
MSVC Static MSVC Clang-CL Build Z3 Cache Memory Safety Mark PRs Ready
MSVC Static Build MSVC Clang-CL Static Build Build and Cache Z3 Memory Safety Analysis Mark PRs Ready for Review

Manual & Release Workflows

Documentation Release Build WASM Release
Documentation Release Build WebAssembly Publish

Specialized Workflows

Nightly Validation Copilot Setup Agentics Maintenance
Nightly Build Validation Copilot Setup Steps Agentics Maintenance

Agentic Workflows

API Coherence Code Simplifier Release Notes Workflow Suggestion Academic Citation
API Coherence Checker Code Simplifier Release Notes Updater Workflow Suggestion Agent Academic Citation Tracker
Issue Backlog Memory Safety Report Specbot Crash Analyzer SMTLIB Benchmark Finder
Issue Backlog Processor Memory Safety Report Specbot Crash Analyzer SMTLIB Benchmark Finder
TPTP Benchmark
TPTP Front-End 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:CF linker option
  • These can be disabled using python scripts/mk_make.py --no-guardcf (Python build) or cmake -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

System Diagram

Interfaces

Power Tools