https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Jakub Jelinek from comment #10) > (In reply to Andrew Macleod from comment #9) > > (In reply to Jakub Jelinek from comment #8) > > > Unfortunately that would mean for the non-equality cases that if > > > lhs.undefined_p () we don't return undefined but false (aka VARYING). > > > Another option is to add those if (op?.undefined_p ()) return false; to > > > both > > > case BRS_TRUE: and case BRS_FALSE:. > > > > Well, if the LHS is undefined, (or even one of the operands) we are > > typically in dead code or edge anyway.. I'm not sure it really matters? > > Ok, I'll test the patch then. > > > An alternate question as well is why is the threader even looking at this > > impossible path. It should know that the branch can never be true > > I think range-op shouldn't assume nothing will call it with UNDEFINED ranges. Oh I wasn't suggesting otherwise,we should be bulletproof. Just wondering why the threader is spending any time evaluating ranges on a path it should know is impossible.
