the relation oracle works on a purely symbolic basis. It assumes for 
instance that x == x, along with everything in the equivalency set.

With the coming introduction of floating point ranges, we have 
circumstances beyond the symbol relation which can affect the result.  
If the range of X may contain a NaN, then  x != x.

Within ranger, folding these sorts of things is not much of an issue.  
For x == x when we invoke fold_range (==, range x, range x, VREL_EQ) 
that will be dispatched to the floating point version of 
operator_equal() which first checks if either operand has a Nan, and if 
so, ignores the incoming equality relation.

Although there are no current clients of the relation oracle outside of 
ranger, I see the potential need for a mechanism to validate any 
relation returned by the oracle with specific ranges or ssa-names.  I 
don't *THINK* we need this within ranger yet, but haven't been able to 
convince myself 100% yet :-).

This patch adds 2 new API entry points to the oracle:

   relation_kind validate_relation (relation_kind k, tree ssa1, tree ssa2);
   relation_kind validate_relation (relation_kind k, vrange &op1, vrange 
&op2);

They basically do what ranger currently does, takes the relation and 
checks to see if folding the appropriate expression with the relation 
returns the expected [1, 1]

ie  it tries folding     fold_range (r, EQ_EXPR, op1, op2, VREL_EQ)  and 
returns either VREL_EQ if the result is [1, 1], or VREL_VARYING 
otherwise.  so if op1 or op2 had a NaN, then we'd get VREL_VARYING .   
The ssa-name version simply uses a value of VARYING of the approrate type.

Anyway, Ive tested it on all the integer code by having the oracle 
always validate any relation it returns. which bootstraps with no 
regressions on 86_64-pc-linux-gnu.

The default I have checked in does not actually call these new 
routines.  but they are there when we need them now.

Andrew

PS. It also allows x == x to be registered to the oracle, which use to 
trap for no really good reason.