[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.