Chandler Carruth <chandlerc at google.com> writes:> The implementations of -Wuninitialized, -Wreturn-type, and a few other > GCC warnings are extremely aggressive. They have high false positive > rates with few benefits. We regularly keep -Wreturn-type working > despite this (see all of the llvm_unreachable after switch > statements),So why not add -Wno-uninitialized and friends to the command line? It seems a better option than simply ignoring warnings and then missing a real bug in the haystack of warning messages.> but the fix to silence GCC's -Wuninitialized false positives actively > degrades the quality of the code -- it forces dead stores to > variables. These dead stores are a waste and prevent tools like > Valgrind from finding very real bugs in the logic which cause a > variable to be left uninitialized.I'm curious about this statement. Can you give an example? I've committed fixes to lots of -Wuninitialized warnings in my tree. It's all just initializing local variables, which shouldn't result in extra stores. -David
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of greened at obbligato.org > Subject: Re: [LLVMdev] Build Failure> It seems a better option than simply ignoring warnings and then missing > a real bug in the haystack of warning messages.Definitely agree with that. Our project coding standards require _zero_ warnings at commit time (but that only applies to our code, not imported libraries).> I've committed fixes to lots of -Wuninitialized warnings in my tree. > It's all just initializing local variables, which shouldn't result in > extra stores.What do you think the initialization is? Something has to write the initial value, and that write is frequently pointless. The real problem with this specific warning is that gcc doesn't properly track that a variable is used only under the same conditions in which it is set. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
On 1/2/2013 10:37 PM, greened at obbligato.org wrote:> Chandler Carruth <chandlerc at google.com> writes: > >> but the fix to silence GCC's -Wuninitialized false positives actively >> degrades the quality of the code -- it forces dead stores to >> variables. These dead stores are a waste and prevent tools like >> Valgrind from finding very real bugs in the logic which cause a >> variable to be left uninitialized. > > I'm curious about this statement. Can you give an example? I've > committed fixes to lots of -Wuninitialized warnings in my tree. It's > all just initializing local variables, which shouldn't result in extra > stores.The logic of the program may be such that the actual store (not the "pre-initialization") always happens before any uses, but the compiler may be unable to prove it. In such case, the added initialization will extend the live range of the object and may result in a register spill. I believe that in the vast majority of cases this is not going to be a problem, and the warning is shown because of the basic nature of the front-end's analysis. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
"Caldarale, Charles R" <Chuck.Caldarale at unisys.com> writes:>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of greened at obbligato.org >> Subject: Re: [LLVMdev] Build Failure > >> It seems a better option than simply ignoring warnings and then missing >> a real bug in the haystack of warning messages. > > Definitely agree with that. Our project coding standards require > _zero_ warnings at commit time (but that only applies to our code, not > imported libraries).So how did these slip in?>> I've committed fixes to lots of -Wuninitialized warnings in my tree. >> It's all just initializing local variables, which shouldn't result in >> extra stores. > > What do you think the initialization is? Something has to write the > initial value, and that write is frequently pointless.It's most likely a store to a register. That's hardly a performance issue. Even a store to the stack has little effect. Really, we're going to ignore errors because we can't afford one store in initialization code?> The real problem with this specific warning is that gcc doesn't > properly track that a variable is used only under the same conditions > in which it is set.That is not always true in the cases I've found. That's the consequence of ignoring warnings. -David
Krzysztof Parzyszek <kparzysz at codeaurora.org> writes:>> I'm curious about this statement. Can you give an example? I've >> committed fixes to lots of -Wuninitialized warnings in my tree. It's >> all just initializing local variables, which shouldn't result in extra >> stores. > > The logic of the program may be such that the actual store (not the > "pre-initialization") always happens before any uses, but the compiler > may be unable to prove it. In such case, the added initialization > will extend the live range of the object and may result in a register > spill.If that's really the case, then the variable is declared much too early and the declaration should be moved.> I believe that in the vast majority of cases this is not going to be a > problem, and the warning is shown because of the basic nature of the > front-end's analysis.It's a problem if we keep ignoring warnings and we miss real bugs because there are so many warning messages that things get lost. I have fixed several dozen warnings now. -David
Krzysztof Parzyszek <kparzysz at codeaurora.org> writes:> The logic of the program may be such that the actual store (not the > "pre-initialization") always happens before any uses, but the compiler > may be unable to prove it. In such case, the added initialization > will extend the live range of the object and may result in a register > spill.I also want to note that this is exactly the kind of premature optimization that Knuth warns about. Is it really worth generating a warning from the compiler to save 1-2 cycles in initialization code when we don't even know that the (extremely slight) performance loss matters? -David
On Thu, Jan 03, 2013 at 12:19:14AM -0600, Caldarale, Charles R wrote:> The real problem with this specific warning is that gcc doesn't > properly track that a variable is used only under the same conditions > in which it is set.Worse, it is one of the most optimizer sensitive warnings in GCC. The combination is what it makes it so problematic. Joerg