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.

C6000-CGT: CGT 8.3.9 - cl6x: Identifying sign-conversion

Part Number: C6000-CGT

While moving from CGT 7.3.8 to CGT 8.3.9, we are facing an issue of sign conversion.

(a*b) >>n   : If either a or b were signed and negative, with 'n' being positive, the result is unsigned

n+(a/b)      : If either a or b were signed and negative, with 'n' being positive, the result is unsigned

With both (a*b) and (a/b) being handled as unsigned, the results are thrown off.

With CGT 7.3.8, (a*b) was handled as signed.

With CGT 8.3.9

  •  Is there a way to disable such a behavior. (or)
  •  Is there a compiler option to identify such sign conversions (in line with -Wsign-conversion, in gcc).
  • Please choose a source file that has one of these problem expressions.  For that source file, please follow the directions in the article How to Submit a Compiler Test Case two times.  Once with version 7.3.8, and once with version 8.3.9.  For each test case, after creating the preprocessed file, please edit it and add a comment near the problem expression that says /* PROBLEM HERE */.  

    Thanks and regards,

    -George

  • Thank you for using a private message to submit a test case.  I understand your situation better.

    For those following along, the problem expressions contain enumeration variables.  Whether such variables are considered signed or unsigned is at the root of this situation.

    This forum thread is not the same as your problem, but it comes very close.  It turns out the sign-ness of enumeration variables is a very tricky thing.  The ANSI standard, common practice in GCC compilers, etc. do not all agree on how it works.  

    Given code like ...

    enum colors { red, green, blue };
    enum colors c1, c2;

    The sign-ness of the enumeration constants red, green, and blue, or the sign-ness of the enumeration variables c1 and c2, is not consistent across all C compilers.

    One way to force it to be signed, and not unsigned, is to add another member to the enumeration, and assign it the value -1.

    enum colors { red, green, blue, forced_to_be_signed = -1 };

    Does this suggested fix resolve your problem?

    Thanks and regards,

    -George

  • Thank you for the response, George. The link you share is in line with my query. My current debacle is running through a large code base to address this change in behavior of newer compiler version. Is there any convenient means to detect similar usecase in code, either via compiler options (similar to -Wsign-conversion, in gcc), or otherwise?

  • Please try using the built-in MISRA checks.  Specifically the one for rule 10.1.  Add the build options --check_misra=10.1 --verbose_diagnostics and you'll see diagnostics similar to ...

    "file.c", line 30: warning #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
          signed int integer_variable1 = (enum_type_variable*integer_variable2)>>3;
                                                             ^

    Please let me know if this suggestion resolves the problem.

    Thanks and regards,

    -George