Reasoning about

floating-point arithmetic
with ACDCL
Unifying Abstract Interpretation and
Decision Procedures

Daniel Kroening
(joint work with Leopold Haller,Vijay D’Silva, Michael Tautschnig, Martin Brain)

9 January 2013
1
Thursday, 17 January 13
 Leopold Vijay Michael
Haller D’Silva Tautschnig

+ Martin Brain
(no photo)

2
Thursday, 17 January 13
 References
• TACAS 2012: paths in floating-point
programs with intervals
• POPL 2013: Framework
• VMCAI 2013: DPLL(T)
• FMCAD 2012: Learning for intervals
• SAS 2012: propositional SAT
3
Thursday, 17 January 13
 Presentation Outline
Part I
Existing approaches to FP - Verification
Manual, Decision Abstract
Semi-automated Procedures Interpretation

Part II
Decision Precise Scalable Abstract
Procedures Interpretation
Ou
rr
ese
arc Abstract Satisfiability
h
4
Thursday, 17 January 13
 Part I

5
Thursday, 17 January 13
 IEEE754 Floating Point Numbers

Special values: 0, +0, 1, 1, NaN

6
Thursday, 17 January 13
 The Pitfalls of FP

I II

III IV

7
Thursday, 17 January 13
 Is this program correct?
(We will ignore the case x=NaN)

8
Thursday, 17 January 13
 What does correctness mean?

Three possible meanings:

• Result is sufficiently close to the real number result

• Result is sufficiently close to the sine function

• The assertion cannot be violated

9
Thursday, 17 January 13
 How can we check correctness?

Manual

Abstract Interpretation Decision Procedures

10
Thursday, 17 January 13
 Requires experts,
expensive, powerful

Manual

Abstract Interpretation Decision Procedures

11
Thursday, 17 January 13
 Abstract Interpretation
Error states do not overlap
Error abstract representation,
hence program is safe

Program traces Abstract representation

• Instead of exploring all executions, explore a single abstract

execution

• Abstract execution contains all concrete executions!

• Highly efficient and scalable, but imprecise

Program is safe
Program Abstract Interpreter
?
12
Thursday, 17 January 13
 Abstract Interpretation

An abstract interpreter modularly uses

operations provided by an abstract domain. Interpreter Abstract
Changing the domain changes the analysis. Domain

Example Signs domain Constants domain

{+, } [ {?} {c | c 2 F P } [ {?}

y=+ y=5
x=+ x=?
z=+ z=?
safe! Possibly unsafe

13
Thursday, 17 January 13
 Abstract Interpretation

An abstract interpreter modularly uses

operations provided by an abstract domain. Interpreter Abstract
Changing the domain changes the analysis. Domain

Example Interval Domain

{[l, u] | l, u 2 Int}
x, y 2 [min(Int), max(Int)]

x, y 2 [min(Int), 1]

x 2 [5, 5], y 2 [min(Int), max(Int)]

x 2 [min(Int), 5], y 2 [min(Int), max(Int)]
14
Thursday, 17 January 13
 Abstract Interpretation
Floating Point Intervals {[l, u] | l, u 2 F P } [ {?}

x 2 [ 1.570796, 1.570796]
result 2 [ 2.216760, 2.216760]
result 2 [ 2.296453, 2.296453]
result 2 [ 2.301135, 2.301135]

Potentially unsafe

15
Thursday, 17 January 13
f floating point computations in the reals (taking the worst possible roundin
rrors explicitly into account), to abstract with real numbers but to implement
Astrée Abstract Interpreter
hanks to a further sound over-approximation, using floats. For example the floa
xpression (x + y) + z is evaluated as in the reals as x + y + z + ε1 + ε2 wher
1 | ≤ "rel .|x + y| + "abs and |ε2 | ≤ "rel .|x + y + ε1 + z| + "abs . The real ε1 encode
•
Mature abstract interpreter by Cousot et. al
ounding errors in the atomic computation (x + y), and the real ε2 encode
ounding errors • in number
Large the atomic computation (x + y + ε1 ) + z. The parameters "re
of domains
nd "abs depends on the floating-point type being used in the analyzed program
•
Sold and
his linearization [7,supported by Absint
8] of arbitrary GmbH is a correct abstraction of th
expressions !n
pproach separates
•
oating pointSuccessful
semanticsin into interval
proving linear
correct largeforms [a0control
avionics , b0 ] + software:
k=1 [ak , b100k
k ]Xk . Thi
lines of the
codetreatment of rounding
in 1h -> highly scalable errors from that of the numerica
bstract domains.
•
Various domains for floating point analysis:

Original traces Ellipses Octagons Intervals

ig. 2. Filter trace Ellipsoid abstraction Octagon abstraction Interval abstraction
16
Thursday, 17 January 13
 Abstract Domains for Floating Point

• Abstract domains are typically formulated over the real or

rational numbers

• Numeric domains rely on mathematical properties such as

associativity which do not hold over floating point numbers
(a + b) + c = a + (b + c)

• Solution (Mine 2004): Interpret operations over floating point

numbers as real number operations + error terms

17
Thursday, 17 January 13
 Imprecision in Abstract Interpretation

• The efficiency of abstract interpreters comes at the cost of

precision. Imprecision is accumulated from three sources:

• Statements

x 2 [ 5, 5] y 2 [ 25, 25]

x 2 [0, 1] x, y 2 [0, 1]

• Control-flow
x 2 [ 1, 1]

• Loops

x, y 2 [1, 1] x 2 [100001, max(Int)]

y 2 [min(Int), max(Int)]
18
Thursday, 17 January 13
ounding errors in the atomic computation (x + y + ε1 ) + z. The parameters "re
nd "abs depends on the floating-point type being used in the analyzed program

n of interval
Imprecision
his linearization [7, 8]
concretisations
of
of x̂
in
arbitrary
and
Abstract
ŷ :
Interpretation
expressions is a correct
! n
abstraction
oating point semantics into interval linear forms [a0 , b0 ] + k=1 [ak , bk ]Xk . This
of the

pproach
mid( separates
(x̂) [ (ŷ)) the treatment of rounding(central errors value
from of
that
ẑ) of the numerica
bstract argmin
y
•
domains.For efficiency
x ,↵y )
(|↵|), 8i reasons,
1 most numeric abstract
(coe↵. of ✏i ) domains
min(↵xi ,↵i )↵max(↵ are
i i convex
P
up( (x̂) [ (ŷ)) ↵0 z
i 1
z
|↵i | (coe↵. of ✏U )
e function returns the interval concretisation of an affine form and
b]) := 12 (a + b) and argmin(|x|) := {x 2 [a, b], |x| is minimal }.
axb

1. By the◆ formula✓of definition 1: ◆ ✓ ◆

+✏1 +2✏2 ŷ = 1 2✏1 +✏2 x̂ [ ŷ = 2 +✏2 +3✏U
Original [
traces Ellipses =
+✏1 +✏2 û = 0 +✏1 +✏2 û [ ûOctagons
= 0 +✏1 +✏2 Intervals
ig. 2. Filter trace Ellipsoid abstraction Octagon abstraction Interval abstraction
û û
2 2

he Simplifiedx̂ Filter Abstract ŷ Domains. The simplified x̂[ŷ filter abstrac

[ =
omains
4 [13]
6 provide2 examples
1 of 4domain-aware 2 abstractions.
2 A6 typical example
simplified filter behavior 2 is traced in Fig. 2 (tracing 2 the sequence D1 in Fig. 3)
nterval and octagonal envelops are unstable because they are rotated and shrunk
little
also at each
define iteration
theConvex
cyclic sodenoted
unfold,
polyhedra that some by (i,corner
c, N ), as Zonotope
always sticks
the one out of the envelop
obtained
lly unrolling
owever, i times the
the ellipsoid loop,2and
of Fig. from then
is stable. First,
19 computing the fixpoint
filter domains use dynamical linear
op functional
Thursday, 17 January 13 iterated c times until convergence, this with at most N
 Imprecision in Abstract Interpretation

What if convex abstractions are too weak?

Error Error

Very common scenario

20
Thursday, 17 January 13
 Abstract Interpretation

Conclusion:

• Very scalable

• Imprecise

• Precise results require experts and research effort

• Expert created domains are moderately reusable

• Feasible for programs with homogenous structure and

behaviour (success in avionics)

21
Thursday, 17 January 13
 References
Floating point abstract domains
A. Chapoutot. Interval slopes as a numerical abstract domain for floating-point variables. SAS 2010

L. Chen, A. Miné and P. Cousot. A sound floating-point polyhedra abstract domain. APLAS 2008

A. Miné. Relational abstract domains for the detection of floating-point run-time errors. ESOP 2004

L. Chen, A. Miné, J. Wang and P. Cousot. An abstract domain to discover interval Linear Equalities.VMCAI 2010

L. Chen, A. Miné, J. Wang and P. Cousot. Interval polyhedra: An Abstract Domain to Infer Interval Linear Relationships. SAS 2009

K. Ghorbal, E. Goubault and S. Putot. The zonotope abstract domain Taylor1. CAV 2009

B. Jeannet, and A. Miné. Apron: A library of numerical abstract domains for static analysis. CAV 2009

D. Monniaux. Compositional analysis of floating-point linear numerical filters. CAV 2005

J. Feret. Static analysis of digital filters. ESOP 2004

F. Alegre, E. Feron and S. Pande. Using ellipsoidal domains to analyze control systems software. CoRR 2009

E. Goubault and S. Putot. Weakly relational domains for floating-point computation analysis. NSAD 2005

E. Goubault. Static analyses of the precision of floating-point operations. SAS 2001

22
Thursday, 17 January 13
 References
Industrial Case Studies

E. Goubault, S. Putot, P. Baufreton, J. Gassino. Static analysis of the accuracy in control systems: principles and experiments.
FMICS 2007

D. Delmas, E. Goubault, S. Putot, J. Souyris, K. Tekkal, F. Védrine. Towards an industrial use of FLUCTUAT on safety-critical
avionics software.  FMICS 2009

J. Souyris and D. Delmas. Experimental assessment of Astrée on safety-critical avionics software. SAFECOMP 2007

J. Souyris. Industrial experience of abstract interpretation-based static analyzers. IFIP 2004

P. Cousot. Proving the absence of run-time errors in safety-critical avionics code. EMSOFT 2007

FP Static Analysers
B. Blanchet, P. Cousot, R. Cousot, J. Feret, L. Mauborgne, A. Miné, D. Monniaux and X. Rival. A static analyzer for large safety-
critical software. SIGPLAN 38(5), 2003

P. Cousot, R. Cousot, J. Feret, L. Mauborgne, A. Miné, D. Monniaux and Xavier Rival. The ASTREÉ analyzer. ESOP 2005

E. Goubault, M. Martel and S. Putot. Asserting the precision of floating-point computations: a simple abstract interpreter. ESOP
2002

23
Thursday, 17 January 13
 Requires experts,
expensive, powerful

Manual

Abstract Interpretation Decision Procedures

Scalable and efficient.
Precise analysis requires experts

24
Thursday, 17 January 13
 Decision Procedures

• Precisely explore a large set of program traces

• For efficiency, represent problem symbolically as satisfiability of a

logical formula

Program traces Error

Program is safe exactly if isTrace(t) ^ error (t) is satisfied by some t

25
Thursday, 17 January 13
 Propositional SAT

S A T S o l v e r Propositional
s a r e E ffi c i e n formula:
t ' = (a _ ¬b) ^ (¬a _ b) ^ ¬b

Is there an assignment to a,b that makes the formula true?

1 0 0 s

1 0 s

1 s

2 0 0 0 2 0 0 1 2 0 0 2 2 0 0 3 2 0 0 4 2 0 0 5 2 0 0 6 2 0 0 7

Decrease in SAT solving time for SAT algorithms

2000-2007
(Malik and Zhang 2009)

26
Thursday, 17 January 13
 Why are SAT solvers so efficient

Probe for solution Learn from failure

failure

• SAT solvers learn from failure

• SAT solvers spot relevance

27
Thursday, 17 January 13
 Decision Procedures

Example

c ! (r = a/32 b)
^ ¬c ! (r = a ⇤32 b)
^ a>0^b>0^r <0

Can be translated to propositional logic using divider and

multiplier circuits

a, b 7! 123456789
The formula evaluates to true
under the following assignment:
r 7! 1757895751
c 7! false
28 Counterexample!
Thursday, 17 January 13
 Bounded Model Checking

Loops require unrolling

before translation

If the loop does not have a known fixed bound,

the result is unrolled up to a chosen depth.

29
Thursday, 17 January 13
 Bounded Model Checking

Unsatisfiable
?
Decision Procedure
Program has bug,
Satisfiable counter-example is returned

30
Thursday, 17 January 13
 FP support in CBMC (2008)

• CBMC implements bit-precise reasoning over floating-point

numbers using a propositional encoding

• Uses IEEE-754 semantics with support various rounding-modes

• Allows proofs of complex, bit-level properties

Thursday, 17 January 13
 Scalability of Propositional
Encoding

• Floating-point arithmetic is flattened to propositional logic

• Requires instantiation of large floating point arithmetic circuits

N Nr.Variables Memory use

5 ~130000 ~90MB

10 ~260000 ~180MB

• Resulting formulas are hard for SAT solvers and take up large
amounts of memory

32
Thursday, 17 January 13
 Related work

Constraint satisfaction
C. Michel, M. Rueher and Y. Lebbah: Solving constraints over floating-point numbers. CP2001

B. Botella, A. Gotlieb and C. Michel: Symbolic execution of floating-point computations. STVR2006

SMT
P. Ruemmer and T. Wahl. An SMT-LIB theory of binary floating-point arithmetic. SMT 2010

A. Brillout, D. Kroening and T. Wahl. Mixed abstractions for floating point arithmetic. FMCAD 2009

R. Brummayer and A. Biere. Boolector: An Efficient SMT Solver for Bit-Vectors and Arrays. TACAS 2009

Incomplete Solvers
S. Boldo, J.-C. Filliâtre and G. Melquiond. Combining Coq and Gappa for Certifying Floating-Point Programs. Calculemus 2009.

33
Thursday, 17 January 13
 Requires experts,
scalable, precise

Manual

Abstract Interpretation Decision Procedures

Scalable. Precise.
Precision requires experts Scalability requires experts

34
Thursday, 17 January 13
 Conclusion Part I
Automatic

De
ion

cis
tat

ion
pre

pro
ter
in

ced
act

u
res
str
Ab

Scalable Theorem proving Precise

Safe ?

Abstract Interpreter Decision Procedures

? Bug

35
Thursday, 17 January 13
 Questions so far?

36
Thursday, 17 January 13
 Part II

37
Thursday, 17 January 13
 Automatic

De
n
atio

cis
ret

ion
erp

pro
i nt

ced
act

ure
str

s
Scalable Ab Precise

We are interested in techniques that are

• scalable
• sufficiently precise to prove safety
• fully automatic

Central insight:
Modern decision procedures are abstract interpreters!
38
Thursday, 17 January 13
 Manually adjusting analysis precision
by abstract partitioning

Error Error

y 2 [ 1, 1]

Potentially unsafe! 39 Safe!

Thursday, 17 January 13
 How do we find the partition automatically?

40
Thursday, 17 January 13
 SAT solving by example

SAT solvers accept formulas in conjunctive normal form

literals

' = (p _ ¬q) ^ . . . ^ (¬r _ w _ q)

| {z } | {z }
clauses

Their main data structure is a partial variable assignment

which represents a solution candidate
V ! {t, f}

41
Thursday, 17 January 13
 SAT solving: Deduction

' = p ^ (¬p _ ¬q) ^ (q _ r _ ¬w) ^ (q _ r _ w)

SAT deduces new facts from clauses:

p 7! t p 7! t
q 7! f

At this point, clauses yield no further information

42
Thursday, 17 January 13
 SAT is Abstract Analysis: Deduction

' = p ^ (¬p _ ¬q) ^ (q _ r _ ¬w) ^ (q _ r _ w)

p 7! t p 7! t
q 7! f

p 2 [1, 1]
The result of deduction is q 2 [0, 0]
identical to applying interval
analysis to the program:

Deduction in a SAT solver is abstract analysis

43
Thursday, 17 January 13
 SAT solving: Decisions

' = p ^ (¬p _ ¬q) ^ (q _ r _ ¬w) ^ (q _ r _ w)

SAT solver makes a “guess”

Pick an unassigned variable and assign a truth value
p 7! t p 7! t
q 7! f q 7! f
r 7! f

Now new deductions are possible

44
Thursday, 17 January 13
 SAT solving: Learning

' = p ^ (¬p _ ¬q) ^ (q _ r _ ¬w) ^ (q _ r _ w)

p 7! t
q 7! f
r 7! f

The variable w would have to be both true and false.

The contradiction is the result of r being assigned to false as part of a

decision. The SAT solver therefore learns that r must be true:
' '^r
45
Thursday, 17 January 13
 SAT solving: Learning

' = p ^ (¬p _ ¬q) ^ (q _ r _ ¬w) ^ (q _ r _ w)

p 7! t p 7! t
q 7! f q 7! f conflict
r 7! f r 7! f
w 7! f
The variable w would have to be both true and false.

The contradiction is the result of r being assigned to false as part of a

decision. The SAT solver therefore learns that r must be true:
' '^r
45
Thursday, 17 January 13
 SAT is Abstract Analysis: Decisions & Learning

' '^r

Decisions and learning in a SAT solver are abstract partitioning

46
Thursday, 17 January 13
 SAT is Abstract Analysis
• Deduction in SAT is abstract interpretation

• Decisions and learning are abstract partitioning

• The SAT algorithm is really an automatic partition

refinement algorithm.

SAT(A)

Domain A
Expanding the scope of SAT
47
Thursday, 17 January 13
 SAT is Abstract Analysis
• Deduction in SAT is abstract interpretation

• Decisions and learning are abstract partitioning

• The SAT algorithm is really an automatic partition

refinement algorithm.
Control

Rich logic,
Programs
SAT(A)
e.g. FP

Data

Boolean
Prop. Logic
programs Domain A
Expanding the scope of SAT
47
Thursday, 17 January 13
Abstract Implication Graph
SAT for programs
c3 : a = 0 c2 : a = 1

DL0 [a  2] [a 1]
n1
c2 : a  1 c3 : a  0 c3 : a 0 c2 : a 1
[a = 1] [a = 0]
c1 : a  2 c4 : a 1 c1 c2 c3 c4

b := 1 b := 1
n2 : b  2 n2 : b 2
n2
b := 2 b := 2
b0
:b0 :b 0
[b = 0]

DL1
nn11 :: aa 
 42
2 c1 :ca1 
: > 42 ¬(n2 : b 1)
c2 : ? n2 : b 2
1 :? SAFE ! find
Generalise!
cut
c3 : ?
maximal wp-underapproximation transformer
c4 : ?

¬(n1 : a  2)

48
Leopold Haller (OUDCS) DPLL is Abstract Interpretation 25 / 33
Thursday, 17 January 13
 Prototype:
Abstract Conflict Driven Learning (ACDL)

• Implementation over floating-point intervals

• Automatically refines an analysis in a way that is

• Property dependent

• Program dependent

• Uses learning to intelligently explore partitions

• Significantly more precise than mature abstract

interpreters

• Significantly more efficient than floating-point decision

procedures on short non-linear programs
49
Thursday, 17 January 13
 More results

13

1000 Astrée
time (s)

100 CBMC

10 CDFL

0.1
0 5 10 15 20 25 30 35 40 45 50 55
benchmark

Fig. 2. Execution times of Astrée, CBMC, and cdfl; wrong results set to 3600s

Average speedup over CBMC ~270x

1000 1000
andom decisions
With learning

100 100

10 10
50
1 1
Thursday, 17 January 13
 Property-dependent Trace Partitioning
Implementation

⇡ ⇡
2 2

51
Thursday, 17 January 13
 Property-dependent Trace Partitioning
Number of partitions vs. tightness of bound
result  2.0
⇡ ⇡
2 2

result -2.0 52
Thursday, 17 January 13
 Property-dependent Trace Partitioning
Number of partitions vs. tightness of bound
result  2.0
⇡ ⇡
result  1.5 2 2

result -1.5

result -2.0 53
Thursday, 17 January 13
 Property-dependent Trace Partitioning
Number of partitions vs. tightness of bound
result  2.0
⇡ ⇡
result  1.5 2 2
result  1.2

result -1.2
result -1.5

result -2.0 54
Thursday, 17 January 13
 Property-dependent Trace Partitioning
Number of partitions vs. tightness of bound
result  2.0
⇡ ⇡
result  1.5 2 2
result  1.2
result  1.1

result
result -1.1
-1.2
result -1.5

result -2.0 55
Thursday, 17 January 13
 Property-dependent Trace Partitioning
Number of partitions vs. tightness of bound
result  2.0
⇡ ⇡
result  1.5 2 2
result  1.2
 1.01
result  1.1
result

result
result -1.01
-1.1
result -1.2
result -1.5

result -2.0 56
Thursday, 17 January 13
 Property-dependent Trace Partitioning
Number of partitions vs. tightness of bound
result  2.0
⇡ ⇡
result  1.5 2 2
result
result 1.2
1.001
1.1
result
result  1.01

result
result
result -1.001
-1.01
-1.1
result -1.2
result -1.5

result -2.0 57
Thursday, 17 January 13
 Current and Future Work

• Develop an SMT solver for floating point logic

• Model on the success of propositional SAT:

S A T S o l v e r s a r e E ffi c i e n t
• Simple abstract domain

• Highly efficient data structures

1 0 0 s

1 0 s

1 s

2 0 0 0 2 0 0 1 2 0 0 2 2 0 0 3 2 0 0 4 2 0 0 5 2 0 0 6 2 0 0 7

58
(Malik and Zhang 2009)
Thursday, 17 January 13
 Current and Future Work

• Develop an SMT solver for floating point logic

• Model on the success of propositional SAT:

S A T S o l v e r s a r e E ffi c i e n t
• Simple abstract domain

• Highly efficient data structures

Rich logic,
Programs
e.g. FP 1 0 0 s

1 0 s

Boolean
Prop. Logic
programs 1 s

2 0 0 0 2 0 0 1 2 0 0 2 2 0 0 3 2 0 0 4 2 0 0 5 2 0 0 6 2 0 0 7

58
(Malik and Zhang 2009)
Thursday, 17 January 13
 MathSAT + ACDCL
FP-ACDCL FP-ACDCL

FP-ACDCL w.o. generalisation

1000 1000
bit-vector encoding (Z3)

100 100

10 10

1 1

0.1 0.1

0.01 0.01
0.01 0.1 1 10 100 1000 0.01 0.1 1 10 100 1000
(a) (b)

59
Thursday, 17 January 13
 Current and Future Work

• Reengineer prototype into a tool for floating point

verification

• Significantly improved efficiency

• Generic interface for integrating abstract domains

• Development and generalisation of heuristics and

learning strategies

60
Thursday, 17 January 13
 Current and Future Work

• Reengineer prototype into a tool for floating point

verification

• Significantly improved efficiency

• Generic interface for integrating abstract domains

• Development and generalisation of heuristics and

learning strategies

Rich logic,
Programs
e.g. FP

Boolean
Prop. Logic
programs

60
Thursday, 17 January 13
 Conclusion - Part II
Automatic

De
ion

cis
tat

ion
pre

pro
ter
in

ced
act

u
res
str
Ab

Scalable Theorem proving Precise

Fully automatic
Scalability ACDL Precision
61
Thursday, 17 January 13
 Thank you for your attention

62
Thursday, 17 January 13