https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447

--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #5)
> I'm surprised by rr_union_table content.
> // VREL_VARYING
>   { VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING,
>     VREL_VARYING, VREL_VARYING, VREL_VARYING },
> is obviously correct, sure, but:
> // VREL_UNDEFINED
>   { VREL_VARYING, VREL_LT, VREL_LE, VREL_GT, VREL_GE, VREL_UNDEFINED,
>     VREL_EQ, VREL_NE },
> is strange, VREL_VARYING union VREL_UNDEFINED be VREL_LT?
> I would have expected
>   { VREL_VARYING, VREL_UNDEFINED, VREL_LT, VREL_LE, VREL_GT, VREL_GE,
>     VREL_EQ, VREL_NE },
> instead.
> I fear other entries are weird too (though rr_intersect_table entries look
> reasonable from quick skimming).
> That said, fixing that will not fix this issue.

hmm. I looks like the table from 
commit ade5531c9dde98c7be005a5c5382739d734797aa
Author: Andrew MacLeod <amacl...@redhat.com>
Date:   Thu May 12 12:00:39 2022 -0400

    Move VREL values to their own enumerated type.

didn't get committed as intended. It seems like the UNDEFINED entry is the only
one affected tho which is why it has not had much impact.   UNDEFINED got moved
from a different point in the enum list to be the second one in that patch,
adnit looks like that line missed the move from 5 to 2... The others seem fine
at a glance.  I will look closer tomorrow.

Reply via email to