https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109274
--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> ---
I will provide a fix today, once I look deeper and settle it. Sorry, I was
busy and incommunicado all weekend.
The real root of the problem seems to be that previously if symbolically op1 ==
op2, we were incorrectly not passing op1 ==/!= op1 relations up the GORI call
chain as we intended.
I fixed that, but the new problem is that we *always* do it if op1 and op2 are
the same symbol. For floating point, that is *not* the case. We have code in
== and != to deal with this, but as you can see, we arent doing any kind of
check..
if (!vrel_ptr && k == VREL_VARYING && op1 == op2)
k = VREL_EQ;
so we are setting them to EQ when they may not be.
Im trying to decide whether to fix this "properly" right now (when we first
create this, we do not have access to the range of op1 yet), or leave the
current behavior and if set_relation doesnt return a proper record, move on.
That would amount to something like:
if (k != VREL_VARYING)
{
vrel.set_relation (k, op1, op2);
if (vrel.kind () != v
vrel_ptr = &vrel;
}
Anyway I'll investigate and submit something today so we can get on with this.
(Or maybe simply recommend your lastest patch to bypass the pointless trap.)
In fact, maybe we should do that anyway... since its obviously correct.. and
then when an appropriate fix is provided we can either also applty it, or defer
it to next release as we see fit.
