On Fri, Oct 10, 2025 at 4:27 AM Sam James <[email protected]> wrote: > > Sandra Loosemore <[email protected]> writes: > > > On 10/9/25 15:00, Sam James wrote: > >> Sandra Loosemore <[email protected]> writes: > >> > >>> On 10/8/25 21:15, Sam James wrote: > >>>> CCP interacts poorly with -Wmaybe-uninitialized in some cases by > >>>> assuming a value > >>>> which stops us warning about it (false negatives). Inform users about > >>>> this > >>>> infamous interaction. > >>>> gcc/ChangeLog: > >>>> PR tree-optimization/18501 > >>>> * doc/invoke.texi (-Wmaybe-uninitialized): Mention interaction > >>>> with > >>>> CCP. > >>>> --- > >>>> That works for me. I've checked this in. > >>>> gcc/doc/invoke.texi | 5 ++++- > >>>> 1 file changed, 4 insertions(+), 1 deletion(-) > >>>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > >>>> index f93fe43733dc..8802d416b30c 100644 > >>>> --- a/gcc/doc/invoke.texi > >>>> +++ b/gcc/doc/invoke.texi > >>>> @@ -8375,7 +8375,10 @@ known to read the object.) Annotating the > >>>> function with attribute > >>>> the object and avoids the warning (@pxref{Common Function > >>>> Attributes}). > >>>> These warnings are only possible in optimizing compilation, > >>>> because otherwise > >>>> -GCC does not keep track of the state of variables. > >>>> +GCC does not keep track of the state of variables. On the other hand, > >>>> +@option{-Wmaybe-uninitialized} is known not to warn in many situations > >>>> +(false negatives) due to optimizations taking advantage of undefinedness > >>>> +of uninitialized uses like constant propagation. > >>>> These warnings are made optional because GCC may not be able to > >>>> determine when > >>>> the code is correct in spite of appearing to have an error. Here is > >>>> one > >>> > >>> I'm sorry, I can't parse this one. Do you maybe mean "optimizations > >>> like constant propagation" instead of "uninitialized uses like > >>> constant propagation"? > >> Read it as: "optimizations like constant propagation taking > >> advantage of > >> uninitialized uses [of variables]". I'll change it to that if you're > >> fine with that phrasing? > > > > Well, I'm confused. If we're not going to tell users what > > optimizations to disable or what other options to use to get the best > > results, what's the purpose of the added text? I guess I know more > > about typical compiler optimization strategies and GCC's in particular > > than most users and since I don't see an immediate connection between > > the warning and constant propagation, I suspect this would be even > > more meaningless to average users. We might as well just tell them > > that some optimizations interfere with -Wmaybe-uninitialized, and > > leave it at that. > > I guess it's a hint for advanced users that they can disable CCP, while > adhering to Richard's request to not encourage it. But if you don't > think it's adding anything, I can certainly understand that too. > > I think if we're going to say "some optimisations", we may as well name > some known problematic ones to help people workaround issues. richi > doesn't want us to name a flag because it's too tempting for people to > slap it in their build flags then. > > What's a good compromise? (I know this is kind of bikesheddy but I hope > to apply some of this to other cases too where appropriate.)
What's the intent? I understood it as warning users that optimization might cause some obvious uninitialized uses to not be diagnosed. -fno-tree-ccp will possibly uncover those but also cause a plethora of other false positives/negatives, so I do not want to suggest that you get better uninit diagnostics with -fno-tree-ccp, because that's simply not true. The solution here would be to do (minimal?) maybe-uninit diagnostics from early uninit instead. Richard. > > > > > -Sandra > > sam
