| CODEGEN-6270 |
Compiler manual incorrectly lists callgraph as option for --analyze |
Fixed |
|
ARM_19.6.0.STS |
|
|
| CODEGEN-6046 |
Header file arm_acle.h is missing the matching brace for extern "C" { |
Fixed |
ARM_19.6.0.STS |
ARM_19.6.0.STS |
|
|
| CODEGEN-6031 |
Expressions/Variable view is not properly resolving some C++ symbols properly |
Fixed |
|
ARM_19.6.0.STS |
None. |
Some variables in the CCS Expressions/Variables view are not demangled correctly. The problem is that the compiler and CCS have different versions of the demangling code, which behave somewhat differently. CCS needs to be updated. |
| CODEGEN-5986 |
Compiler may crash when auto as return type of uninstantiated member function in template class resolves to template paramet |
Fixed |
ARM_19.6.0.STS |
ARM_19.6.0.STS |
Avoid "auto" as the return type of a member function if its immediate resolution is a template parameter.
Or explicitly instantiate the class or function. In the given test case, there's a variable defined with type EventSubscriberTable<int>. To avoid the problem, then, include either
template class EventSubscriberTable<int>;
or
template auto EventSubscriberTable<int>::getBroadcastList(void);
in the source file. |
Given a class definition like
template <typename T>
class Table {
public :
auto getList(void) { return m_Callbacks; }
private :
T m_Callbacks;
};
where the member function getList() returns "auto" and that "auto" can be seen to be "T", and this program:
int main(int argc, char* argv[])
{
Table<int> m_Table;
return 0;
}
in which the Table class is instantiated but the function getList() is never used, the compiler may crash.
The problem requires the combination of auto, template parameter, and uninstantiated function. Changing any of those details will avoid it. |
| CODEGEN-5943 |
Compiler may lose volatile qualifier in A->B->C when B and C are both volatile |
Fixed |
ARM_19.6.0.STS |
ARM_19.6.0.STS |
The expression has to contain both dereferences, eg, a->b->c, for the problem to appear. If they're separated by using a temp, as in
T * volatile p;
p = a->b;
... p->c ...
then the problem should be avoided. Making the temp "p" volatile is also important, to prevent the compiler from recombining the two dereferences.
Or compile with -o1, -o0, or -ooff. |
In an expression like A->B->C, when B and C are both volatile structure fields, we'd expect to see two distinct memory accesses every time. There is a bug in the compiler specifically with having two dereferences in a single expression, ie, A->B->C, in which it may lose the volatile qualifier from B. That may lead it to save A->B in a temporary variable and reuse that value instead of re-reading it as is supposed to happen. |
| CODEGEN-5924 |
ARM compiler error with 64-bit constant decomposed into 2 16-bit constants |
Fixed |
ARM_19.6.0.STS |
ARM_19.6.0.STS |
One workaround is to change the negative constant in the assembly file to its unsigned equivalent and recompile the assembly file. In this case, the option to keep the assembly file must be used. The negative constant causing the compiler error should be converted to its binary representation, and that representation converted to an unsigned number. |
A load of a 64-bit source constant such as the following example, which can be broken into 2 16-bit constants for bits 0-15 and 32-47 (bits 16-31 and 48-64 are 0), may incorrectly emit a negative constant in the assembly file, causing the assembler to issue an error.
For example:
unsigned long long x = 0xca0600006274; |
| CODEGEN-5791 |
C++ enum class with explicit type has some problems |
Fixed |
ARM_19.6.0.STS |
ARM_19.6.0.STS |
Avoid specifying an explicit base type for an enum. |
Values of a C++ enum class type with an explicit base type may not be cast properly to and from integral types. The exact conditions depend on undefined behavior, and thus are not 100% predictable; the known cases happen only on Windows, though the compiler uses the same codebase on all platforms. |
| CODEGEN-5773 |
--emit_references:file causes an internal error on Mac |
Fixed |
ARM_19.6.0.STS |
ARM_19.6.0.STS |
|
|
| CODEGEN-5674 |
Under -o4, compiler may assume a global variable is constant, if it's only set in files containing inline asm() |
Fixed |
ARM_19.6.0.STS |
ARM_19.6.0.STS |
First, compiling with -o3 (or less) instead of -o4 will avoid the problem.
Second, making g_sys_opmode volatile does indeed work around the problem. Since the "volatile" qualifier tells the compiler that something is modifying the variable outside the compiler's view, that's exactly what is needed to keep it from being assumed constant.
Third, removing the asm() from main.c will work around the problem, by including main.c in the recompilation. I modified EINT/DINT and EALLOW/EDIS macros in F2806x_Device.h and two cpu.h files, making them use the intrinsics __enable_interrupts, __disable_interrupts, __eallow, and __edis. As it happens, __enable_interrupts and __disable_interrupts control both INTM and DBGM, while the macros control them individually, so this may not be a completely satisfactory solution. |
The immediate trigger for the bug is that main.c contains asm() statements. That's the only file that sets g_sys_opmode; other files only read it. The presence of asm() keeps the file out of the recompilation that -O4 does. The compiler, however, still thinks it has the whole program (or at least the important parts); since it doesn't see main.c, it doesn't see the writes, and concludes that g_sys_opmode is a constant 0. |
| CODEGEN-5574 |
Loop controlled by unsigned char counter iterates more than 255 times |
Fixed |
ARM_19.6.0.STS |
ARM_19.6.0.STS |
Compile at -o1 or less, or restructure the loop to make it not need the 8-bit wraparound. |
A do-while loop with an unsigned loop variable narrower than int can miss one of its wraparound cases, for instance if the loop counts down and the counter starts at zero. The compiler may promote the variable to int, making it wider than the original and thus it will experience a much larger count when it wraps. |
| CODEGEN-5533 |
Loop with Cortex-R, -mf3, and DWARF debug leads to assembler error "defined differently in each pass" |
Fixed |
ARM_19.6.0.STS |
ARM_19.6.0.STS |
Several pieces have to come together for this problem to happen.
--opt_for_speed needs to be 3 or greater; thus a workaround is to reduce optimization to --opt_for_speed=1.
The source code has to have one or more IFs, followed by a nested scope that isn't part of a compound statement and defines local variables, followed by a loop. Another workaround is thus to move the local variable definitions to the enclosing scope. (Another that works for the given test case but isn't necessarily general is to initialise all those local variables, where they're defined in the nested scope.)
Normal debug info must be present; a final workaround is therefore to use --symdebug:none to suppress debug info. Of course, that makes debugging difficult. |
The assembler will become confused when presented with the sequence of a .align, an instruction that is smaller than the specified alignment, a label, and the DWARF DW_AT_low_pc directive. Because of the way it processes alignments and labels in different passes, it will conclude that the label was defined with two different values, and report an error.
This sequence is not something a human asm programmer would write. It arises from compiling a particular shape of statements in a loop, with a particular set of compilation options, to position the label and the .align and the directive. See the Workaround, which also indicates how to modify the code or compiler options to avoid this bug. |
| CODEGEN-5486 |
Global constexpr class errors out when assigning to member data |
Fixed |
ARM_19.6.0.STS |
ARM_19.6.0.STS |
The error can be avoided If the constexpr class definition is wrapped in a function which simply returns the instance of the class.
For example:
constexpr MyClass getA()
{ MyClass A("This is a constant literal"); return A;}
Using 'getA()' instead of 'A' will work as expected. |
Constexpr class definitions may generate spurious parser errors, including one about "accessing expired storage." |
| CODEGEN-5119 |
Using #pragma RETAIN does not keep a static file level variable |
Fixed |
ARM_19.6.0.STS |
ARM_19.6.0.STS |
Use both "#pragma RETAIN" and "__attribute__((used))" at the same time. |
The RETAIN pragma may not keep an unused variable like it's supposed to. |
| CODEGEN-4931 |
Applying __attribute__((used)) to static variable does not work |
Fixed |
|
ARM_19.6.0.STS |
|
|
| SDSCM00052006 |
ltoa definition conflicts with quasi-standard ltoa |
Fixed |
|
ARM_19.6.0.STS |
Don't use ltoa; instead use sprintf. |
For a long time, the TI RTS has defined a function named ltoa used in printf. However, quasi-standard function ltoa with a different prototype has been floating around the net for even longer. The presence of TI's definition causes problems for applications which attempt to use ltoa. It's difficult for the user to override the definition in their program to use the quasi-standard version, because TI has a prototype for the bogus version in stdlib.h
This defect has been resolved by renaming TI's ltoa to something in the implementation namespace. Additionally, we've added a definition of ltoa conforming to the quasi-standard version. |
