On Thu, Jul 24, 2025 at 4:23 AM Jeff Law via Gcc <gcc@gcc.gnu.org> wrote: > > > > On 7/23/25 5:45 PM, Andrew Pinski via Gcc wrote: > > 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. > I'll hopefully channel Richi correctly here ;-) Emitting this kind of > warning from an optimization pass should be avoided.
Yep. > So the tradeoff is better optimization (concrete examples) vs missing > some uninit warnings. I tend to lean towards the former, but I realize > my views may be in the minority. I'm questioning the idea of simply removing a store from uninit - the store still represents a change of the effective type. What you are essentially doing (or what you should do) is to do path isolation on specific uninit uses - which will have unintended consequences as with all of such "new" exploitation of undefined behavior. But just removing a single stmt is not something we should do IMO. So can I ask you to instead try amending path isolation with this case? Not that I believe it's a good idea, but that would be the place to do sth about this. Richard. > Jeff >
