Coverity Scan Does Not Run on rtems6

[Joel Sherrill]

This is a ticket to note that Coverity does not appear to like the gcc version going from one to two digits. Since the Coverity Scan support for free users is minimal, I asked on the GCC mailing list if anyone had insight (​https://gcc.gnu.org/pipermail/gcc/2020-October/234073.html).

This is completely outside our control and this is just a tracking ticket to note that Coverity Scan reports will be run against the 5 branch until this is fixed. This will likely be of limited use since rtems 5 is stable and changes are minimal compared to the rtems master.

If it really is a two digit major issue (unconfirmed if this works for gcc 9), I could do Coverity builds using a special toolchain based on gcc 9.

[Joel Sherrill]

I have done some more analysis which I reported in the GCC mailing list thread. I build sparc-rtems6 tools using gcc 7, 8, 9, and 10. Coverity worked using GCC 7, 8, and 9 but not 10 using the autoconf build since that made it more similar to gcc 7 on rtems5. It required uninstalling Coverity and reinstalling each time I switched GCC versions. There must be some residual configuration left between runs which this addresses.

I did try the waf build with gcc 7, 9, and 10. Same behavior as with the autoconf build.

The questions going forward are:

• Is there a way to make Coverity aware of a bug like this? Support for the open source projects using Coverity Scan is minimal.

• Do we want to switch to the master for Coverity runs? This would require me using a special gcc9 build. The code on rtems5 is stable and any fixes/changes are much more likely to be on the master so I tend to lean to switching.

This is going to be an issue until Coverity updates the binary for Scan to support GCC 10.

[Joel Sherrill]

Coverity Scan has been running on RTEMS for a while now. Closing.

[Joel Sherrill]

Didn't get closed last time.