RFC/RFH: uninit warning vs DSE of store from a known uninitialized variable

[Andrew Pinski]

> -----Original Message-----
> From: Andrew Pinski <apinski@qti.qualcomm.com>
> Sent: Wednesday, July 23, 2025 4:45 PM
> To: gcc@gcc.gnu.org
> Subject: RFC/RFH: uninit warning vs DSE of store from a
> known uninitialized variable
> 
> Hi all,
>   When I improved DSE to remove stores where the rhs is
> known 100% to be an uninitialized variables
> (ssa_undefined_value_p), I get a few regressions due to an
> uninitialized warning does not happen:
> gcc.dg/uninit-40.c for an example.
> (gcc.dg/analyzer/torture/boxed-int-1.c fails also for a similar
> reason).
> Does it make sense to warn at the same time as removing
> these stores that the variable is uninitialized? Or should we
> delay to removing the stores until right before the expansion
> of Gimple to RTL?
> These stores show up more often with C++ code so removing
> them early as possible would be a good idea.
> 
> Any other options I didn't think of?

There is another option, change the testcase to make use of an uninitialized variable NOT a store but rather in an addition.
Like:
-  q[7] = bar (pw + 3 * sizeof (unsigned));             /* { dg-warning "'\\*\\(int \\*\\)\\(&w\\\[1\\\]\\\[1\\\]\\)' is used uninitialized" } */
+  q[7] = 1 + bar (pw + 3 * sizeof (unsigned));         /* { dg-warning "'\\*\\(int \\*\\)\\(&w\\\[1\\\]\\\[1\\\]\\)' is used uninitialized" } */

This can be done as we don't "optimize" `uninit + 1` into just `uninit` at this stage. But it does seem like we should do in the future. Should we warn at that point in the similar sense as I recommended for the store case too?

Thanks,
Andrew


> 
> Thanks,
> Andrew Pinski