<div dir="ltr"><div dir="ltr">On Thu, Jun 10, 2021 at 10:42 AM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div><br></div></div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 10, 2021 at 10:20 AM David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Do the reports have deltas? (highlighting new defects with as fine revision granularity as possible) or do they only show the total set of findings at a given revision?</div></blockquote><div><br></div><div><div style="color:rgb(0,0,0)">Yes (see below sample email from today), which is why I'd prefer to keep this daily rather than weekly. </div></div></div></div></div></div></blockquote><div><br>Ah, cool - thanks!<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div style="color:rgb(0,0,0)">llvm-commits@ may be more suitable than llvm-dev@ for this?</div></div></div></div></div></div></blockquote><div><br>Yeah, not sure. I don't feel too strongly either way. <br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">From Coverity:</div><div style="color:rgb(0,0,0)"><br>Please find the latest report on new defect(s) introduced to llvm found with Coverity Scan.<br><br>8 new defect(s) introduced to llvm found with Coverity Scan.<br>19 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.<br><br>New defect(s) Reported-by: Coverity Scan<br>Showing 8 of 8 defect(s)<br><br><br>** CID 1457502: Uninitialized members (UNINIT_CTOR)<br>/lld/MachO/InputSection.h: 109 in lld::macho::StringPiece::StringPiece(unsigned long, unsigned int)()<br></div></div></div></div></div></div></blockquote><div><br>Is it easy for us to disable low-value findings (both on a per-instance, but also per-check-tye) basis in source (ie: without having to modify an external config)?<br><br>For instance, I'm not sure it's valuable for us to get notification on any member not initialized by a ctor. That could readily be detected by clang-tidy or clang warnings and we don't implement such checks in those places (which would be higher value because they can find the issue sooner rather than waiting for a long-running static analysis to come back with results).<br><br>Keeping the warnings low-noise would be really important (so whoever set this up or requested it I hope is really pushing to reduce the noise until nearly all results have pretty broad agreement that they should be fixed).<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div style="color:rgb(0,0,0)"><br><br>________________________________________________________________________________________________________<br>*** CID 1457502: Uninitialized members (UNINIT_CTOR)<br>/lld/MachO/InputSection.h: 109 in lld::macho::StringPiece::StringPiece(unsigned long, unsigned int)()<br>103 // Offset from the start of the containing input section.<br>104 uint32_t inSecOff;<br>105 uint32_t hash;<br>106 // Offset from the start of the containing output section.<br>107 uint64_t outSecOff;<br>108 <br>>>> CID 1457502: Uninitialized members (UNINIT_CTOR)<br>>>> Non-static class member "outSecOff" is not initialized in this constructor nor in any functions that it calls.<br>109 StringPiece(uint64_t off, uint32_t hash) : inSecOff(off), hash(hash) {}<br>110 };<br>111 <br>112 // CStringInputSections are composed of multiple null-terminated string<br>113 // literals, which we represent using StringPieces. These literals can be<br>114 // deduplicated and tail-merged, so translating offsets between the input and<br><br>** CID 1457501: Uninitialized members (UNINIT_CTOR)<br>/llvm/lib/ObjectYAML/XCOFFEmitter.cpp: 36 in <unnamed>::XCOFFWriter::XCOFFWriter(llvm::XCOFFYAML::Object &, llvm::raw_ostream &, llvm::function_ref<void (const llvm::Twine &)>)()<br><br><br>________________________________________________________________________________________________________<br>*** CID 1457501: Uninitialized members (UNINIT_CTOR)<br>/llvm/lib/ObjectYAML/XCOFFEmitter.cpp: 36 in <unnamed>::XCOFFWriter::XCOFFWriter(llvm::XCOFFYAML::Object &, llvm::raw_ostream &, llvm::function_ref<void (const llvm::Twine &)>)()<br>30 <br>31 class XCOFFWriter {<br>32 public:<br>33 XCOFFWriter(XCOFFYAML::Object &Obj, raw_ostream &OS, yaml::ErrorHandler EH)<br>34 : Obj(Obj), W(OS, support::big), ErrHandler(EH) {<br>35 Is64Bit = Obj.Header.Magic == (llvm::yaml::Hex16)XCOFF::XCOFF64;<br>>>> CID 1457501: Uninitialized members (UNINIT_CTOR)<br>>>> Non-static class member "StartOffset" is not initialized in this constructor nor in any functions that it calls.<br>36 }<br>37 bool writeXCOFF();<br>38 <br>39 private:<br>40 bool initFileHeader(uint64_t CurrentOffset);<br>41 bool initSectionHeader(uint64_t &CurrentOffset);<br><br>** CID 1457500: Incorrect expression (SIZEOF_MISMATCH)<br>/compiler-rt/lib/dfsan/dfsan_custom.cpp: 2367 in format_buffer(char *, unsigned long, const char *, unsigned char *, unsigned char *, unsigned int *, unsigned int *, __va_list_tag *)()<br><br><br>________________________________________________________________________________________________________<br>*** CID 1457500: Incorrect expression (SIZEOF_MISMATCH)<br>/compiler-rt/lib/dfsan/dfsan_custom.cpp: 2367 in format_buffer(char *, unsigned long, const char *, unsigned char *, unsigned char *, unsigned int *, unsigned int *, __va_list_tag *)()<br>2361 case 'n': {<br>2362 int *ptr = va_arg(ap, int *);<br>2363 *ptr = (int)formatter.str_off;<br>2364 va_labels++;<br>2365 if (va_origins)<br>2366 va_origins++;<br>>>> CID 1457500: Incorrect expression (SIZEOF_MISMATCH)<br>>>> Passing argument "ptr" of type "int *" and argument "8UL /* sizeof (ptr) */" to function "dfsan_set_label" is suspicious.<br>2367 dfsan_set_label(0, ptr, sizeof(ptr));<br></div></div></div></div></div></div></blockquote><div><br></div><div>I think clang has a sizeof warning for things like memcpy, right? I wonder if this more broad warning provides a lot of value, or not?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div style="color:rgb(0,0,0)">2368 end_fmt = true;<br>2369 break;<br>2370 }<br>2371 <br>2372 case '%':<br><br>** CID 1457499: Incorrect expression (DIVIDE_BY_ZERO)<br>/llvm/lib/Analysis/CFGPrinter.cpp: 308 in llvm::DOTGraphTraits<llvm::DOTFuncInfo *>::isNodeHidden(const llvm::BasicBlock *, const llvm::DOTFuncInfo *)()<br><br><br>________________________________________________________________________________________________________<br>*** CID 1457499: Incorrect expression (DIVIDE_BY_ZERO)<br>/llvm/lib/Analysis/CFGPrinter.cpp: 308 in llvm::DOTGraphTraits<llvm::DOTFuncInfo *>::isNodeHidden(const llvm::BasicBlock *, const llvm::DOTFuncInfo *)()<br>302 const DOTFuncInfo *CFGInfo) {<br>303 if (HideColdPaths.getNumOccurrences() > 0)<br>304 if (auto *BFI = CFGInfo->getBFI()) {<br>305 uint64_t NodeFreq = BFI->getBlockFreq(Node).getFrequency();<br>306 uint64_t EntryFreq = BFI->getEntryFreq();<br>307 // Hide blocks with relative frequency below HideColdPaths threshold.<br>>>> CID 1457499: Incorrect expression (DIVIDE_BY_ZERO)<br>>>> In expression "(double)NodeFreq / EntryFreq", division by expression "EntryFreq" which may be zero has undefined behavior.<br>308 if ((double)NodeFreq / EntryFreq < HideColdPaths)<br>309 return true;<br>310 }<br>311 if (HideUnreachablePaths || HideDeoptimizePaths) {<br>312 if (isOnDeoptOrUnreachablePath.find(Node) == <br>313 isOnDeoptOrUnreachablePath.end())<br><br>** CID 1457498: (DEADCODE)<br>/clang/lib/Sema/SemaDeclCXX.cpp: 11843 in clang::Sema::CheckUsingShadowDecl(clang::BaseUsingDecl *, clang::NamedDecl *, const clang::LookupResult &, clang::UsingShadowDecl *&)()<br>/clang/lib/Sema/SemaDeclCXX.cpp: 11789 in clang::Sema::CheckUsingShadowDecl(clang::BaseUsingDecl *, clang::NamedDecl *, const clang::LookupResult &, clang::UsingShadowDecl *&)()<br><br><br>________________________________________________________________________________________________________<br>*** CID 1457498: (DEADCODE)<br>/clang/lib/Sema/SemaDeclCXX.cpp: 11843 in clang::Sema::CheckUsingShadowDecl(clang::BaseUsingDecl *, clang::NamedDecl *, const clang::LookupResult &, clang::UsingShadowDecl *&)()<br>11837 return true;<br>11838 }<br>11839 <br>11840 // No conflict between a tag and a non-tag.<br>11841 if (!NonTag) return false;<br>11842 <br>>>> CID 1457498: (DEADCODE)<br>>>> Execution cannot reach this statement: "<temporary> = this->Diag(cl...".<br>11843 Diag(BUD->getLocation(), diag::err_using_decl_conflict);<br>11844 Diag(Target->getLocation(), diag::note_using_decl_target);<br>11845 Diag(NonTag->getLocation(), diag::note_using_decl_conflict);<br>11846 BUD->setInvalidDecl();<br>11847 return true;<br>11848 }<br>/clang/lib/Sema/SemaDeclCXX.cpp: 11789 in clang::Sema::CheckUsingShadowDecl(clang::BaseUsingDecl *, clang::NamedDecl *, const clang::LookupResult &, clang::UsingShadowDecl *&)()<br>11783 // Always emit a diagnostic for a mismatch between an unresolved<br>11784 // using_if_exists and a resolved using declaration in either direction.<br>11785 if (isa<UnresolvedUsingIfExistsDecl>(Target) !=<br>11786 (isa_and_nonnull<UnresolvedUsingIfExistsDecl>(NonTag))) {<br>11787 if (!NonTag && !Tag)<br>11788 return false;<br>>>> CID 1457498: (DEADCODE)<br>>>> Execution cannot reach this statement: "<temporary> = this->Diag(cl...".<br>11789 Diag(BUD->getLocation(), diag::err_using_decl_conflict);<br>11790 Diag(Target->getLocation(), diag::note_using_decl_target);<br>11791 Diag((NonTag ? NonTag : Tag)->getLocation(),<br>11792 diag::note_using_decl_conflict);<br>11793 BUD->setInvalidDecl();<br>11794 return true;<br><br>** CID 1457497: Integer handling issues (NEGATIVE_RETURNS)<br><br><br>________________________________________________________________________________________________________<br>*** CID 1457497: Integer handling issues (NEGATIVE_RETURNS)<br>/lld/MachO/InputSection.cpp: 117 in lld::macho::CStringInputSection::getStringPiece(unsigned long) const()<br>111 const StringPiece &CStringInputSection::getStringPiece(uint64_t off) const {<br>112 if (off >= data.size())<br>113 fatal(toString(this) + ": offset is outside the section");<br>114 <br>115 auto it =<br>116 partition_point(pieces, [=](StringPiece p) { return p.inSecOff <= off; });<br>>>> CID 1457497: Integer handling issues (NEGATIVE_RETURNS)<br>>>> A negative constant "-1L" is passed as an argument to a parameter that cannot be negative.<br></div></div></div></div></div></div></blockquote><div><br></div><div>Doesn't sound correct - negatively indexing from an iterator is valid, I believe? (though perhaps this check is using some info about the nature of `partition_point` being able to return the begin iterator)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div style="color:rgb(0,0,0)">117 return it[-1];<br>118 }<br>119 <br>120 uint64_t CStringInputSection::getFileOffset(uint64_t off) const {<br>121 return parent->fileOff + getOffset(off);<br>122 }<br><br>** CID 1457496: Possible Control flow issues (DEADCODE)<br>/clang/lib/Sema/SemaDeclCXX.cpp: 11833 in clang::Sema::CheckUsingShadowDecl(clang::BaseUsingDecl *, clang::NamedDecl *, const clang::LookupResult &, clang::UsingShadowDecl *&)()<br><br><br>________________________________________________________________________________________________________<br>*** CID 1457496: Possible Control flow issues (DEADCODE)<br>/clang/lib/Sema/SemaDeclCXX.cpp: 11833 in clang::Sema::CheckUsingShadowDecl(clang::BaseUsingDecl *, clang::NamedDecl *, const clang::LookupResult &, clang::UsingShadowDecl *&)()<br>11827 // Target is not a function.<br>11828 <br>11829 if (isa<TagDecl>(Target)) {<br>11830 // No conflict between a tag and a non-tag.<br>11831 if (!Tag) return false;<br>11832 <br>>>> CID 1457496: Possible Control flow issues (DEADCODE)<br>>>> Execution cannot reach this statement: "<temporary> = this->Diag(cl...".<br>11833 Diag(BUD->getLocation(), diag::err_using_decl_conflict);<br>11834 Diag(Target->getLocation(), diag::note_using_decl_target);<br>11835 Diag(Tag->getLocation(), diag::note_using_decl_conflict);<br>11836 BUD->setInvalidDecl();<br>11837 return true;<br>11838 }<br><br>** CID 1419078: Resource leaks (VIRTUAL_DTOR)<br>/llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp: 541 in ()<br><br><br>________________________________________________________________________________________________________<br>*** CID 1419078: Resource leaks (VIRTUAL_DTOR)<br>/llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp: 541 in ()<br>535 return (Twine(Removed ? "-" : " ") + (InMST ? " " : "*") +<br>536 (IsCritical ? "c" : " ") + " W=" + Twine(Weight)).str();<br>537 }<br>538 };<br>539 <br>540 // This class stores the auxiliary information for each BB.<br>>>> CID 1419078: Resource leaks (VIRTUAL_DTOR)<br>>>> Class "<unnamed>::BBInfo" does not have a virtual destructor.<br>541 struct BBInfo {<br>542 BBInfo *Group;<br>543 uint32_t Index;<br>544 uint32_t Rank = 0;<br>545 <br>546 BBInfo(unsigned IX) : Group(this), Index(IX) {}<br><br><br>________________________________________________________________________________________________________<br>To view the defects in Coverity Scan visit, <a href="https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yqtGMuad6pPsL7inW23sAqZCWZD0rQ5FZsyk18zSjnBpg-3D-3Dqen7_nlj59xHPRAo5NMSpMZh-2B1UYnQ4IBJNE2FCxtFGv5-2FfRZ2ZNTfin-2BJg3vqHM-2BrKWO-2BwAgQVf1GGFXh4xVX9UzXjq3jPiI59xzjIzanRxv0XSIVZFqDyJd-2BdQm4cXqcdS7Dt0L1fNQpWyw15e-2BbU4YMt1YpKZVa4kbM7Bjl6hGDatG6tnUuz5zUAdmlq-2B7z2QmYSc2DTghseWofWoq-2Bn7ssA-3D-3D" rel="noreferrer" target="_blank">https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yqtGMuad6pPsL7inW23sAqZCWZD0rQ5FZsyk18zSjnBpg-3D-3Dqen7_nlj59xHPRAo5NMSpMZh-2B1UYnQ4IBJNE2FCxtFGv5-2FfRZ2ZNTfin-2BJg3vqHM-2BrKWO-2BwAgQVf1GGFXh4xVX9UzXjq3jPiI59xzjIzanRxv0XSIVZFqDyJd-2BdQm4cXqcdS7Dt0L1fNQpWyw15e-2BbU4YMt1YpKZVa4kbM7Bjl6hGDatG6tnUuz5zUAdmlq-2B7z2QmYSc2DTghseWofWoq-2Bn7ssA-3D-3D</a><br><br> To manage Coverity Scan email notifications for "<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>", click <a href="https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yped04pjJnmXOsUBtKYNIXxUrjVeIJ0Cfeziujhnhh3yxzc7w9MgExjQKEssnVrR9tYRoPYlaXXfdUjwRQLJCdFixsrT7mUhUA9ixc9DPUdquU2MMNgdrF247xaBicB0V4-3Dht-M_nlj59xHPRAo5NMSpMZh-2B1UYnQ4IBJNE2FCxtFGv5-2FfRZ2ZNTfin-2BJg3vqHM-2BrKWOP6G0-2FiydipnYxIKl-2Bk7AFFr9CcUjQXx7tq4qtWbpBdzz7-2Bib4DWeMAf-2Bv0hl9c0qiwYnDVi4C3uD0F0P9wRuATKCNq-2FJGcnjmQ51zJUZdom9QcwJ2QwYMBBjOk8G2ylW4oH3PujCpojyn5dsLN7qdQ-3D-3D" rel="noreferrer" target="_blank">https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yped04pjJnmXOsUBtKYNIXxUrjVeIJ0Cfeziujhnhh3yxzc7w9MgExjQKEssnVrR9tYRoPYlaXXfdUjwRQLJCdFixsrT7mUhUA9ixc9DPUdquU2MMNgdrF247xaBicB0V4-3Dht-M_nlj59xHPRAo5NMSpMZh-2B1UYnQ4IBJNE2FCxtFGv5-2FfRZ2ZNTfin-2BJg3vqHM-2BrKWOP6G0-2FiydipnYxIKl-2Bk7AFFr9CcUjQXx7tq4qtWbpBdzz7-2Bib4DWeMAf-2Bv0hl9c0qiwYnDVi4C3uD0F0P9wRuATKCNq-2FJGcnjmQ51zJUZdom9QcwJ2QwYMBBjOk8G2ylW4oH3PujCpojyn5dsLN7qdQ-3D-3D</a><div></div></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 10, 2021 at 7:37 AM Luke Benes via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> <a href="https://scan.coverity.com/projects/llvm" rel="noreferrer" target="_blank">https://scan.coverity.com/projects/llvm</a><br>
> Should run once a day.<br>
<br>
Sylvester,<br>
The report seems to be working perfectly. Thank you for taking the time to get this up and running again!<br>
<br>
My only concern is that there is no visibly on these reports. Without the new issues being reported here, it is highly unlikely that they will get addressed. <br>
<br>
Since there was interest and no objections, could you please add the [llvm-dev] list to the email? <br>
<br>
You can do this by going to the "Project Settings" page:<br>
<a href="https://scan.coverity.com/projects/llvm?tab=project_settings" rel="noreferrer" target="_blank">https://scan.coverity.com/projects/llvm?tab=project_settings</a><br>
<br>
"Additional Emails for New Defect Notifications"<br>
-> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<br>
Then could you please lower the report frequency to once or twice a week? With that we will receive weekly reports like this:<br>
<br>
<a href="http://document-foundation-mail-archive.969070.n3.nabble.com/New-Defects-reported-by-Coverity-Scan-for-LibreOffice-td4301203.html" rel="noreferrer" target="_blank">http://document-foundation-mail-archive.969070.n3.nabble.com/New-Defects-reported-by-Coverity-Scan-for-LibreOffice-td4301203.html</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div></div>
</blockquote></div></div>