<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 29, 2021 at 6:15 AM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.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="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 29, 2021, 6:49 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</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">Hello Matthew,<br>
<br>
On 29/01/2021 10:14, Matthew J Fletcher wrote:<br>
> Hi,<br>
><br>
> Does RTEMS trunk roughly follow GCC releases ?,. i've seen discussion <br>
> of GCC 11 on the dev mailing list.<br>
you can already try out the GCC 11 based tools with the experimental <br>
RTEMS 7 tool chain available in the RSB.<br>
><br>
> I wonder if we (RTEMS users) could take advantage of the new static <br>
> analysis options in GCC 11.<br>
><br>
> <a href="https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/" rel="noreferrer noreferrer" target="_blank">https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/</a> <br>
> <<a href="https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelopers.redhat.com%2Fblog%2F2021%2F01%2F28%2Fstatic-analysis-updates-in-gcc-11%2F&data=04%7C01%7Cmatthew.fletcher%40se.com%7Cb41c34faa0154d5137e908d8c42830b3%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637475024180771568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SmQ4xfLBvYSeQUx0xd0jKC2z%2F89gRLH6IrHg17EJmUI%3D&reserved=0" rel="noreferrer noreferrer" target="_blank">https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelopers.redhat.com%2Fblog%2F2021%2F01%2F28%2Fstatic-analysis-updates-in-gcc-11%2F&data=04%7C01%7Cmatthew.fletcher%40se.com%7Cb41c34faa0154d5137e908d8c42830b3%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637475024180771568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SmQ4xfLBvYSeQUx0xd0jKC2z%2F89gRLH6IrHg17EJmUI%3D&reserved=0</a>> <br>
><br>
><br>
><br>
> Would seem very useful for embedded projects where runtime analysis is <br>
> difficult.<br>
Yes, you can give it a try. I never used it myself. The Coverity scan <br>
alone keeps me busy.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Agreed. I had privately chatted with Gedare about this. He and some students had planned to or have looked at llvm's analyzer but this should be an easy step.</div><div dir="auto"><br></div><div dir="auto">The question on all these types analysis tools is how to manage the output. As a project, we do Coverity runs on leon3 for consistency. BSP doesn't matter for you if you want to pick at issues. But if it has warnings now, this will only increase the number. </div><div dir="auto"><br></div><div dir="auto">And it would be nice to think in terms of having automated reports available for the community and a scoreboard of some sort to track progress.</div><div dir="auto"><br></div><div dir="auto">But honestly, I've been reporting on warnings and analysis issues for years. Sometimes filing tickets. Sometimes fixing. It is an endless quest and hard to get broad help.</div><div dir="auto"><br></div><div dir="auto">In fairness, issues in common code gets fixed. Issues in random device drivers can tend to linger.</div><div dir="auto"><br></div><div dir="auto">Please experiment and report.</div></div></blockquote><div>Hi Matt,</div><div><br></div><div>Yes, if you're interested, we can talk more about looking into the GCC static analyzer jointly. I will get around to it when I get around to it :) Probably in April or May. I did get a student to product results from clang-analyzer also, but haven't turned that into production-grade yet.  The big issue is triage and integration with workflows, and that is something that requires work and thought from both the contributors and the project maintainers.</div><div><br></div><div>Gedare</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="auto"><div dir="auto"><br></div><div dir="auto">--joel</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><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">
<br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" rel="noreferrer" target="_blank">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax:   +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
<br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" rel="noreferrer" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a></blockquote></div></div></div>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a></blockquote></div></div>