Compiler/TM4C129CNCZAD: BUG: Compiler misreports MISRA rule 12.7

For the source file which includes the problem C code, please follow the directions in the article How to Submit a Compiler Test Case.

Thanks and regards,

-George

George Mock

Respectfully, the page you linked to is asking for quite a bit of additional work when the snippet of code I supplied should be enough for any TI engineer interested in fixing compiler bugs to reproduce.  I stripped out dependencies on headers (with the exception of TI's libraries) and other things (which I cannot send you anyway) and distilled it down to just the problem code.  The compiler version this happens on is 18.1.1, but I cannot be sure it didn't happen in prior versions, I only know that it did not happen on 15.12.6.  If you need more information I'd be happy to supply it, but I think what I've posted should be enough to go on.

In most cases, it takes more time to read the article than to do what it asks.  The article addresses concerns about protecting your code.  But none of that is the main point.

The main point is accuracy.  TI releases many (100? 200?) software packages.  Each package has multiple versions.  Even within one specific package, it is common to have multiple variants of the same header file, each with slight differences.  While a compiler diagnostic usually refers to only one source line, the surrounding context often matters.  Supplying a preprocessed source file, as described in the article, avoids all these problems.  The article requests the build options, exactly as they are seen by the compiler.  Lastly, it requests the compiler version, which you supplied.

With regard to a single report, the relative importance of these different details varies.  But across lots of reports, all of these details matter.  That is why the article requests them.  With all the details requested in the article, you can be confident we will reproduce the precise problem you see, for the very same reasons.  Isn't that what you want?

With regard to your specific report ...  I searched through the few packages I happen to have installed, and based on that, cobbled together a test case which gets a MISRA 12.7 diagnostic.  But I also discovered this diagnostic is very sensitive to the signness of each operand in the expression.  Because I had to guess at a few things, I am not certain I see the MISRA 12.7 for the same reason.

Therefore, it makes sense to continue to request a test case as described in the article How to Submit a Compiler Test Case.

With regard to protecting your code, here is another idea to consider ... After creating the preprocessed source file, you could manually remove the functions, types, etc that are not needed by the problem source line.  I admit that could take some time, and may not be practical.

Thanks and regards,

-George

I totally get that. I can understand how getting every bit of information is more likely to lead to a more reproducible test case. Consider this: your customers are usually posting here because they're trying to get something done and have hit a wall on the road to getting that thing done (whether or not its due to a bug). I'm believer in reporting bugs so that it can get fixed, so I try to go through that effort where I have time to, but if I have to go put in a non-trivial amount of effort to report a bug that I can work around with a trivial amount of work, I'm less likely to report that bug.

Is it not in TI's best interest to keep the activation energy of filing a bug relatively low so that you hear about such feedback and bugs?

With regard to this specific bug, it sounds like you were able to reproduce it. I'd appreciate it if you could file a bug in your bug tracking system to get it fixed (as that's not something I can do directly). If you need more feedback from me, I'd be happy to try and offer it. If you absolutely cannot reproduce it, I'll see if I can set aside some time to perform some additional steps, but at that point I think I'd rather just live with the pragma I already put in to except the rule and work around the bug.

I'm pretty confident you hit the same case if you used the code I posted.  Unless I'm missing something (which is possible), there's nothing signed (implicitly or explicitly) in those lines, and they didn't generate this error in the 15.12.6 version of the compiler, but they do in later versions like 18.1.1. Thanks for your help!