• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 1136 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CCS/TMS320F280049: Does latest CCS 8.x or even 9.x supports MISRA-C 2012?

Compiler/TMS320F280049: MISRA-C 2004 check is different in C28x and CLA?

Wayne Huang
Genius 15645 points
Part Number: TMS320F280049

Tool/software: TI C/C++ Compiler

Champs,

I am asking this for our customer.

The user's environment is:

CCS : 8.3.0.00009

Compiler : TI v 18.1.4.LTS

It's weird they got much different results by MISRA-C 2004 when they compiled the same code in C28x and CLA.

On CLA, they got much more warning on the codes.

The warnings are basically Rule 10.1 and 12.2 like below:

#1393-D (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if the expression is complex
#1393-D (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if the expression is complex
#1393-D (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if the expression is complex
#1487-D (MISRA-C:2004 12.2/R) The value of an expression shall be the same under any order of evaluation that the standard permits
#1393-D (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if it is not a conversion to a wider integer type of the same signedness
#1393-D (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if it is not a conversion to a wider integer type of the same signedness
#1393-D (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if it is not a conversion to a wider integer type of the same signedness
#1393-D (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if it is not a conversion to a wider integer type of the same signedness
#1393-D (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if it is not a conversion to a wider integer type of the same signedness

Our questions:

1) Why above codes get passed on C28x (right) but get many warnings on CLA (left)?

2) Is there any special restrictions with CLA when we try to implement MISRA-C 2004 checking?

Do you have any comment?

Wayne Huang

  • 0
    TI__Guru**** 244300 points

    It is probably related to the fact that the type int is different sizes.  On C28x, it is 16-bits.  On CLA, it is 32-bits.  For instance, this statement ...

        short_variable = int_variable;

    ... gets no MISRA diagnostic when built as C code, but sees diagnostic 10.1 when built as CLA code.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Genius 15645 points
    George,

    In the user’s code above, it seems they already have explicit casting like U16.
    So, do you mean even there are explicit casting in the codes, there will still be such warning because CLA has different sizes of int from C28x?

    Wayne
  • 0 in reply to Wayne Huang
    TI__Guru**** 244300 points

    To explain things with that level of detail, I need a test case which allows me to reproduce the diagnostic.  For the source file which gets the MISRA diagnostics, please follow the directions in the article How to Submit a Compiler Test Case.  But with one difference.  I need to see exactly how the file is built for CLA, and for C28x.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru**** 244300 points

    Please supply the requested test case.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Genius 15645 points

    George,

    We tried to use a simple project to reproduce this issue and found the underlying "int" might be the issue, just as you said.

    If we cast the "int" correctly, we don't see the issue.

    We will check with the user in more detail.

    Therefore, this issue can be closed now.

    If there is any new related issue, I will post another.

    Thank you very much.

    Wayne Huang