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