destructive equality resolution uses an occurs check function that is only safe for quantifier-free formulas. In the special case where a bound variable is Boolean and occurs on a side of an equality the other side cannot have a quantifier.
Fix missing <cstdint> include in src/util/tptr.h that causes build
failure with GCC 13:
```
In file included from /tmp/z3/src/util/region.cpp:53:
/tmp/z3/src/util/region.cpp: In member function ‘void* region::allocate(size_t)’:
/tmp/z3/src/util/tptr.h:29:62: error: ‘uintptr_t’ does not name a type
29 | #define ALIGN(T, PTR) reinterpret_cast<T>(((reinterpret_cast<uintptr_t>(PTR) >> PTR_ALIGNMENT) + \
| ^~~~~~~~~
/tmp/z3/src/util/region.cpp:82:22: note: in expansion of macro ‘ALIGN’
82 | m_curr_ptr = ALIGN(char *, new_curr_ptr);
| ^~~~~
/tmp/z3/src/util/region.cpp:57:1: note: ‘uintptr_t’ is defined in header ‘<cstdint>’; did you forget to ‘#include <cstdint>’?
56 | #include "util/page.h"
+++ |+#include <cstdint>
57 |
```
* Logical names for function declarations in c++
Currently, for example, the function declaration symbol member for
checking whether multiplication *does not* overflow is called
`m_bv_smul_ovfl`. Since we are introducing the upcoming smtlib2 symbols
that check that multpliciation *does* overflow, the not overflow check
symbols are renamed to `m_bv_smul_no_ovfl` etc.
* Implement smtlib overflow preds for multiplication
Smtlib2 is being extended to include overflow predicates for bit
vectors (see https://groups.google.com/u/1/g/smt-lib/c/J4D99wT0aKI).
This commit introduces the predicates `bvumulo` and `bvsmulo` that
return `true` if the unsigned multiplication overflows or the signed
multiplication underflows or overflows, respectively.
* Move mul overflow predicates to BV logic
* Add a todo on illogical argument order
* Implement mk_unary_pred for bv
* Implement bvnego
* Implement bvuaddo
* Implement bvsaddo
* Implement bvusubo
* Implement bvssubo
* Implement bvsdivo
* implement Optimize class for the high level Typescript API
* javascript and wasm: add _malloc to exported functions
fix the bug https://github.com/Z3Prover/z3/issues/6709
* javascript: add tests for the Optimize class
* javascript: no reason that minimize and optimize must be constants
- scan_for_linear returns true if it finds a new linear equation. It then should break GB.
- if scan_for_linear returns false, it should still allow try_modify_eqs.
This behavior was masked by requiring scan_for_linear to always be true before
allowing try_to_modify_eqs.
based on repro from Guido Martinez @mtzguido
deals with fluke regression for F* reported by Guido Martinez
Background:
The automatic pattern inference facility looks for terms that contains all bound variables of a quantifier. It may end up with a term that contains all bound variables but the extracted term can be simplified.
Example. The pattern
(ApplyTT (ApplyTT @x3!1 (ApplyTT @x4!0 (:var 1))) (ApplyTT @x4!0 (:var 0)))
can be decomposed into a multi-pattern
(ApplyTT @x4!0 (:var 1))) (ApplyTT @x4!0 (:var 0))
The multi-pattern may enable a quantifier instantiation while the original pattern does not. The multi-pattern should be preferred.
The regression showed up based on a change that should not be considered harmful but turned out to be noticeable.
The change was a simplification of and-or expressions based on sorting. This played with the case split queue used by F* (smt.case_split = 3) that uses a top-level case split of clauses to avoid redundant branches. The net effect was that without sorting, the benchmarks would always choose the opportune branch that enabled matching against the larger term. With sorting it would mostly choose inopportune branches.
* before rm lu
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
* rm get_column_in_lu_mode
* rm lu
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
* rm lu
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
* rm_lp
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
* rm_lu
* rm lu
* rm lu
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
* rm lu
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
* rm lu
* rm lu
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
* rm lu
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
* rm lu
* cleanup
* rm breakpoints
* rm dealing with doubles
* Revert "rm dealing with doubles"
This reverts commit 547254abe7.
* rm lu
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
* rm lu
* rm lu
* rm scaler
* rm square_sparse_matrix
* more cleanup
* rm dead code
* rp precise
* remove many methods dealing with double
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
* rm lu related fields from lp_core_solver_base.h
* remove dead code
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
* more dead code removal
* remove more dead code
* more dead code
* rm dead code
* more dead code
* fix lp_tst
* more dead code
* replace lp_assert(false) with UNREACHABLE
* rm non feas costs
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
* fix the build
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
---------
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
Hello, I was looking at the different api string conversions for FuncEntry and I believe that the ml version is incorrect? Clearly we want the argument(`c`) to be comma separated from the accumulated string `p`. The current implementation just so happens to have most of the arguments separated, but the order is flipped and one of the commas is misplaced.
