<div dir="ltr"><div dir="ltr">On Fri, Jun 11, 2021 at 2:07 PM Tom Honermann <<a href="mailto:Thomas.Honermann@synopsys.com">Thomas.Honermann@synopsys.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>
<p><br>
</p>
<div>On 6/11/2021 2:40 PM, David Blaikie wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Jun 11, 2021 at 8:15 AM Tom Honermann <<a href="mailto:Thomas.Honermann@synopsys.com" target="_blank">Thomas.Honermann@synopsys.com</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>
<div>On 6/11/2021 9:58 AM, Tom Honermann via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div>On 6/10/2021 2:54 PM, David Blaikie via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On Thu, Jun 10, 2021 at 10:42 AM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">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>
<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>
</div>
</div>
</div>
</div>
</blockquote>
<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)">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>
</div>
</div>
</div>
</blockquote>
<p>Source annotations are available for suppressing per-instance issues, but no source annotations are available to disable checkers entirely.</p>
<p>I don't see an option for disabling specific checkers in Coverity Scan.  Checker enable/disable and tuning options are available when using a Coverity installation.  I don't know why those capabilities wouldn't be exposed to Coverity Scan users.<br>
</p>
</blockquote>
I confirmed with internal Coverity support that such options are not currently exposed to Coverity Scan users.  Enhancement requests sent to
<a href="mailto:scan-admin@coverity.com" target="_blank">scan-admin@coverity.com</a> will be considered for future Coverity Scan updates (I encourage sending an enhancement request).<br>
</div>
</blockquote>
<div><br>
Having not setup the scanning/emails/etc I don't think I have enough context (I'm not exactly a "user" - at best I've read one email produced by the tool) to make a feature request.
<br>
</div>
</div>
</div>
</blockquote>
Understood. If you find yourself unhappy with the results of any particular checker, I'll be happy to work with you, Sylvestre, or anyone else interested to craft an ER.<br>
<blockquote type="cite">
<div dir="ltr">
<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>
<blockquote type="cite">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><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>
</div>
</div>
</div>
</blockquote>
</blockquote>
<p>I'm going to push back on this a bit.  I've had to debug problems in Clang that turned out to be due to failure to initialize a data member.  I find the number of uninitialized data member issues that Coverity reports on LLVM to be out of line with respect
 to other projects I've seen scanned.  I'm skeptical that omitting initializers has a significant impact on performance.<br>
</p>
</div>
</blockquote>
<div>The tradeoff is that initializing values that aren't meant to be used reduces msan's ability to identify bugs if such a value is really used.</div>
</div>
</div>
</blockquote>
<p>Yes, fair enough.  Perhaps there is a way to provide a poisened initializer that is (effectively) elided when msan is enabled and used otherwise?</p>
<p><font face="monospace">struct S {<br>
  int *p = POISON(nullptr);<br>
};</font></p></div></blockquote><div><br></div><div>Fair, I'd be open to something like that I think.</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><p><br>
</p>
<p>Tom.<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<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>
<p></p>
<p>Coverity doesn't report every data member that isn't initialized by a member init; it looks for evidence that the data member is not initialized by any functions invoked by the constructor as well (whether in the same TU or not).  It will therefore report
 fewer FPs than either clang-tidy or clang warnings.<br>
</p>
<p>Tom.<br>
</p>
<blockquote type="cite">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><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>
</div>
</div>
</blockquote>
<p>Yes, the general deployment recommendation is to tune to minimize FPs and low value results and then relax such tuning as issues are addressed.<br>
</p>
<p>Tom.<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<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)"><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://urldefense.com/v3/__https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yqtGMuad6pPsL7inW23sAqZCWZD0rQ5FZsyk18zSjnBpg-3D-3Dqen7_nlj59xHPRAo5NMSpMZh-2B1UYnQ4IBJNE2FCxtFGv5-2FfRZ2ZNTfin-2BJg3vqHM-2BrKWO-2BwAgQVf1GGFXh4xVX9UzXjq3jPiI59xzjIzanRxv0XSIVZFqDyJd-2BdQm4cXqcdS7Dt0L1fNQpWyw15e-2BbU4YMt1YpKZVa4kbM7Bjl6hGDatG6tnUuz5zUAdmlq-2B7z2QmYSc2DTghseWofWoq-2Bn7ssA-3D-3D__;!!A4F2R9G_pg!PQwy8rAjiKMI_cBfDwnfPHyGD0k6TmR-QczpyNJJYgHISD-Qk1-6wPLjy535GVbE$" 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://urldefense.com/v3/__https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yped04pjJnmXOsUBtKYNIXxUrjVeIJ0Cfeziujhnhh3yxzc7w9MgExjQKEssnVrR9tYRoPYlaXXfdUjwRQLJCdFixsrT7mUhUA9ixc9DPUdquU2MMNgdrF247xaBicB0V4-3Dht-M_nlj59xHPRAo5NMSpMZh-2B1UYnQ4IBJNE2FCxtFGv5-2FfRZ2ZNTfin-2BJg3vqHM-2BrKWOP6G0-2FiydipnYxIKl-2Bk7AFFr9CcUjQXx7tq4qtWbpBdzz7-2Bib4DWeMAf-2Bv0hl9c0qiwYnDVi4C3uD0F0P9wRuATKCNq-2FJGcnjmQ51zJUZdom9QcwJ2QwYMBBjOk8G2ylW4oH3PujCpojyn5dsLN7qdQ-3D-3D__;!!A4F2R9G_pg!PQwy8rAjiKMI_cBfDwnfPHyGD0k6TmR-QczpyNJJYgHISD-Qk1-6wPLjy8RFYZYc$" 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>
<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="https://urldefense.com/v3/__http://document-foundation-mail-archive.969070.n3.nabble.com/New-Defects-reported-by-Coverity-Scan-for-LibreOffice-td4301203.html__;!!A4F2R9G_pg!PQwy8rAjiKMI_cBfDwnfPHyGD0k6TmR-QczpyNJJYgHISD-Qk1-6wPLjy7OhpJPm$" 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://urldefense.com/v3/__https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!A4F2R9G_pg!PQwy8rAjiKMI_cBfDwnfPHyGD0k6TmR-QczpyNJJYgHISD-Qk1-6wPLjy7Im7VZf$" 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://urldefense.com/v3/__https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!A4F2R9G_pg!PQwy8rAjiKMI_cBfDwnfPHyGD0k6TmR-QczpyNJJYgHISD-Qk1-6wPLjy7Im7VZf$" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a href="https://urldefense.com/v3/__https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!A4F2R9G_pg!PQwy8rAjiKMI_cBfDwnfPHyGD0k6TmR-QczpyNJJYgHISD-Qk1-6wPLjy7Im7VZf$" target="_blank">https://urldefense.com/v3/__https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!A4F2R9G_pg!PQwy8rAjiKMI_cBfDwnfPHyGD0k6TmR-QczpyNJJYgHISD-Qk1-6wPLjy7Im7VZf$</a> 
</pre>
</blockquote>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a href="https://urldefense.com/v3/__https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!A4F2R9G_pg!OqS--6HaZxcTx5Dt_tzjIpH37pYd3W0dBZqRxguX9IqfSIEm0LR2kmIPuSCtBYp1$" target="_blank">https://urldefense.com/v3/__https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!A4F2R9G_pg!OqS--6HaZxcTx5Dt_tzjIpH37pYd3W0dBZqRxguX9IqfSIEm0LR2kmIPuSCtBYp1$</a> 
</pre>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>

</blockquote></div></div>