This patch adds VREL_OTHER to represent another relation we do not 
understand.  It is used to represent the class fo relations arising from 
floating point that are currently not represented. IN GCC 14 we will 
determine exactly how to represent them, but for this release, this 
should prevent us from getting things wrong at least.

if intersection produces UNDEFINED and either of the relations feeding 
it were <, <=, >, or >=   then it turns it to VR_OTHER.   the prevents 
false sides of branches from combining to produce  UNDEFINED when they 
end up being a known NAN.

Union is adjusted such that < >, or <= >= also produce VREL_OTHER.   < > 
cannot be properly represented, and <= >= was producing VARYING, which 
is also not correct.

Form the testcase:

     <bb 2> :
     cmp1_10 = x_8(D) <= y_9(D);
     cmp2_11 = x_8(D) >= y_9(D);
     _3 = cmp1_10 & cmp2_11;
     if (_3 != 0)
       goto <bb 3>; [INV]
     else
       goto <bb 4>; [INV]

Relational : (x_8(D) == y_9(D))
     <bb 3> :
     // predicted unlikely by early return (on trees) predictor.
     goto <bb 6>; [INV]


     <bb 4> :
     _4 = ~cmp1_10;
     _5 = ~cmp2_11;
     _1 = cmp1_10 | cmp2_11;
     _6 = ~_1;
     if (_1 != 0)
       goto <bb 6>; [INV]
     else
       goto <bb 5>; [INV]

Relational : (x_8(D) unknown fp y_9(D))
     <bb 5> :
     // predicted unlikely by early return (on trees) predictor.


The intersection "fix" is represented by the relation between x and y in 
BB5.  Without the patch, ti would be UNDEFINED and we do not want that.

The union fix is what prevents us from folding the condition in bb_4.  
Without it, x<=y union x >=y comes out VARYING, when in fact I believe 
it represents everything except a NAN.

So with this fix, all the unrepresentative relations get lumped into 
VREL_OTHER so we at least don't get it wrong.  For next release we can 
take the time to figure out exactly how we want to proceed.

This is currently in testing on x86_64-pc-linux-gnu, and assuming it 
bootstraps with no regressions (a combined patch did before splitting it 
in 2), OK for trunk?   OR does it need more tweaking?

Andrew