On 10/27/25 11:37 AM, Andrew Pinski wrote:
On Mon, Oct 6, 2025 at 8:41 AM Andrew Pinski
<[email protected]> wrote:
SRA likes to create VCE<bool>(a) when it comes to bool. This confuses
a few different passes including jump threading and uninitialization
warning. This removes the VCE in one case where it will help and when it
is known not to have any undefined behavior since the ranges of a is known
to be 0/1.
This implements similar was done for PR 80635 but without VRP's help; ccp
provides enough on the range/non-zeroness to implement this in match.
This will fix many of the std::optional reported warnings at -O1 too.
pr80635-[34].C are the same as pr80635-[12].C but compiled at -O1 rather
than just -O2.
Ping?
Yes this is different from
https://gcc.gnu.org/pipermail/gcc-patches/2025-September/694386.html .
The difference is the range check here would not cause any information
to be lost as the range of the inner name is already known to be
`[0,1]`. So it should be safer and more to what we want.
Plus VRP already does this exact transformation (with the range info);
that was added with r11-7383-g3cf52b87ff693. We should do it in
match-and-simplify and not just VRP. After ccp, the range of the
variable is already set to `[0,1]` so transforming afterwards is a
good idea.
Thanks,
Andrew
PR tree-optimization/105749
PR tree-optimization/80635
gcc/ChangeLog:
* match.pd (`VCE<bool>(zero_one_valued_p) ==\!= 0`): New pattern.
gcc/testsuite/ChangeLog:
* g++.dg/warn/pr80635-3.C: New test.
* g++.dg/warn/pr80635-4.C: New test.
OK. Given its limited to the 0/1 valued case we should be good here.
And as you noted it should help at least some of the middle-end warnings
such as uninit. I know Andrew M. and I looked at least one of these
deeply a few years back. We concluded that it wasn't generally safe to
drop the V_C_E, but what you've done looks much safer than what we were
considering.
jeff
