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.

Compiler/ARM-CGT: update requests for next ARM-CGT release

Expert 1226 points

Part Number: ARM-CGT
Other Parts Discussed in Thread: HALCOGEN

Tool/software: TI C/C++ Compiler

Hello,

We're looking ahead to our roadmap for firmware updates to our product line which uses the TMS57LC4357, an ARM Cortex-R5F-based microcontroller, and are evaluating our timeline for updating our certification for TI's ARM code generation tools.

I appreciate that TI has recently released the v20.2.1.LTS update to ARM-CGT.  What are TI's plans for follow-on updates?

There are some specific known issues with ARM-CGT that we would be quite interested in seeing fixed:

CODEGEN-4304 C++ feature causes runtime failure on unaligned access on ARM9

This issue is very hard for us to mitigate.  My understanding (see the discussion in https://e2e.ti.com/support/tools/ccs/f/81/t/832858 ) is that correctly written code could experience a catastrophic error at runtime, and there is no guidance as to what code might or night not be vulnerable--that even the reference to "C++" is misleading, as this could potentially happen to C code as well.  Our only recourse is to say "we haven't seen it during our in-house testing, so hopefully we won't see it happen in the field", which is a tough position to take when supporting a safety-related product where human injury is a possibility.

CODEGEN-662 Double constant incorrectly converted to float changes result slightly

I appreciate that the actual "physical" (so to speak) impact of this issue is likely to be very small.  However, I hope that you can appreciate that the effort it takes to mitigate this issue when releasing firmware is quite large!

Essentially we need to review every usage of double-precision math in our entire firmware, including that of any third-party code (including TI-provided HALCoGen or other code) and determine if, despite the designer's presumed intent by using double-precision calculations to begin with, that each calculation is safe because either it A) didn't really need to be using double-precision to begin with, or B) it does not make use of a double-precision literal (which might be multiple macro levels deep) which is vulnerable to this issue.

CODEGEN-1059 Compiler does not respect partial overrides in C99 designated initializers

Similarly, this presents a significant analysis for releasing firmware.  While we do not generally make a practice of specifying the same sub-object multiple times during initialization, verifying this during release takes a significant amount of effort.  (If you are aware of any static analysis tools that include a check for this, that would be quite helpful!)

What are TI's plans for working on these issues?  What is the prospect for an updated release on what kind of timeline which incorporates a fix to one or more of these issues?

Any information you can provide would be quite helpful for us when considering our own roadmap.

--thx

  • We are taking a closer look at each of these issues, and plan to develop more detail about them.  We'll post here when there is more to report.

    Thanks and regards,

    -George

  • 1138 said:
    CODEGEN-4304 C++ feature causes runtime failure on unaligned access on ARM9

    After further discussion and review, we conclude that this one is user error, and not a bug in the compiler.  The related entry has been updated with the details.

    The other two are still under review.  Please continue to be patient.

    Thanks and regards,

    -George

  • Regarding ...

    1138 said:
    CODEGEN-662 Double constant incorrectly converted to float changes result slightly

    The external entry has been updated with more details about the conditions which lead to the problem.  That should make it easier for you to see that your code does not have those conditions.

    Thanks and regards,

    -George

  • Regarding ...

    1138 said:
    CODEGEN-1059 Compiler does not respect partial overrides in C99 designated initializers

    We plan to fix this problem.

    Here is another example which illustrates the problem.

    typedef struct {
        int i1;
        int i2;
        int i3_array[2];
    } inner_t;
    
    typedef struct {
        int	o1;
        inner_t o2_struct;
    } outer_t;
    
    inner_t inner_global = {
        .i2 = 53,
        .i1 = 52,
        .i3_array[1] = 29,
        .i3_array[0] = 28
    };
    
    outer_t outer_global;
    
    void fxn(void)
    {
        outer_t outer_local = {
            1,
    	.o2_struct = inner_global,     /* AAA */
    	.o2_struct.i2 = 51,            /* BBB */
    	.o2_struct.i3_array[1] = 27
        };
    
        outer_global = outer_local;
    
        /* outer_global.o2_struct.i1 is not 52, but 0          */
        /* outer_global.o2_struct.i3_array[0] is not 28, but 0 */
    }

    The problem begins with the line marked AAA.  It should assign a value to all the inner_t fields.  But the line marked BBB causes all of the inner_t fields to be 0, and then initializes .o2_struct.i2.  The comments at the end indicate which inner_t fields are wrong.

    The problem may occur anytime a subsequent designated initializer overlaps a previous designated initializer.

    Thanks and regards,

    -George