https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #18 from Andrew Macleod <amacleod at redhat dot com> --- Created attachment 54312 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54312&action=edit possible patch The only place I think it matters is in set_one_relation. THis is the central point where we add a new relation, and search for any relations leading to this point. If we find one, then we perform an intersection and register the result. If we also check for floating point operands, and see a LT, LE, GT, or GE involved in the intersection, and the result is EQ or NE, this patch simply doesn't register the new relation so combining <= and >= will simply leave the relation as <= instead of producing == Its not incorrect, just not exact.. but we have no way of representing the exact result yet. I think this is the only place we really use intersection, and the oracle does not use union for anything. We never merge incoming results that way.. we simply search the dominators rather than create new relations for merge points. THis probably needs to be checked in the path oracle too.. I dont think there are any other combinations of relations that will cause a problem?
