https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #17 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #4) > Phiopt does this: > ``` > v_13 == 1 ? 1 : LookupFlags_6 > Matching expression match.pd:1990, gimple-match-5.cc:23 > Matching expression match.pd:1990, gimple-match-5.cc:23 > Matching expression match.pd:2479, gimple-match-4.cc:35 > Matching expression match.pd:2482, gimple-match-3.cc:66 > Matching expression match.pd:2489, gimple-match-2.cc:58 > Matching expression match.pd:1947, gimple-match-7.cc:20 > Applying pattern match.pd:4742, gimple-match-7.cc:15326 > Folded into the sequence: > _17 = v_13 == 1; > _18 = LookupFlags_6 | _17; > Removing basic block 5 > ;; basic block 5, loop depth 1 > ;; pred: 4 > ;; succ: 6 > ``` > As zero_one_valued_p returns true for LookupFlags_6 because > tree_nonzero_bits/get_nonzero_bits returns 1 for it. > > So it is ranger in the end that returns that it has a nonzero bits of 1. > Which is completely wrong as LookupFlags_6 is defined by: > # LookupFlags_6 = PHI <LookupFlags_9(D)(2), LookupFlags_5(5)> > > > Which has an uninitialized variable in it which is not defined at what its > value would be .... BTW, it doesn't seem ranger would be involved here at all, since this bug happens with -O1, and evrp nor VRP* run at this level. The only other way ranger could be involved at -O1 is through DOM threading's use of ranger, but phiopt1 from which your dump above comes from, runs before DOM. I realize further downthread y'all conclude this is an unitialized issue, but I'm just trying to understand how ranger could have been involved. FWIW, there are other passes which set global nonzero bits at -O1, most notably CCP. Theoretically any pass which calls set_range_info() or set_nonzero_bits() would alter everyone's view of a range (strlen pass, PRE, DOM, sprintf, CCP, etc). And way down on the list of likely scenarios is fold_range() being called with a global query object. This would get ranger involved in folding something with known global values (no additional lookups), but it's unlikely. You probably got a nonzero bits from some other pass.
