Richard Biener <[email protected]> writes: > 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.
That was my intent, then I wanted a bonus hint for developers which pass is likely to cause the trouble. But given.. > -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. > this.. I think it's indeed counterproductive or at least "only helpful if you know the details already". Personally, I'm fine with the text as it is on trunk now: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized. It names the type of problem (which helps people understand why it's a hard problem) but doesn't name the pass (so doesn't encourage bad behaviour). sam
