| CODEGEN-6270 |
Compiler manual incorrectly lists callgraph as option for --analyze |
Fixed |
|
C2000_19.6.0.STS |
|
|
| CODEGEN-6131 |
C28 fast int div: FPU load scheduling issue |
Fixed |
|
C2000_19.6.0.STS |
Either disable fast integer division --idiv_support=none, or if using fast integer division, --idiv_support=idiv0, avoid using the specific case for the I64/UI64 fast integer division. |
For the C2000 fast integer division feature, --idiv_support=idiv0, FPU register loads could incorrectly move ahead of the ABSxxDIVxx instruction in a fast integer division sequence.
This could only happen for the I64/UI64 fast integer division case. |
| CODEGEN-6020 |
C28 fast int div: reduce unnecessary CPU to FPU MOVs |
Fixed |
|
C2000_19.6.0.STS |
Higher optimization levels, --opt_level=2 or greater, helped to offset this issue. |
For fast integer division feature, --idiv_support=idiv0, cases involving I64, UI64, I16 and UI16 were loading integer values to FPU registers by first loading to CPU registers, followed by the CPU-to-FPU register moves which add extra delay slots. |
| CODEGEN-5960 |
Dynamic libraries are not supported on targets other than C6000 |
Fixed |
C2000_19.6.0.STS |
C2000_19.6.0.STS |
|
|
| CODEGEN-5943 |
Compiler may lose volatile qualifier in A->B->C when B and C are both volatile |
Fixed |
C2000_19.6.0.STS |
C2000_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-5862 |
C2000 intrinsic __rpt_mov_imm fails to compile with negative source literal |
Fixed |
C2000_19.6.0.STS |
C2000_19.6.0.STS |
N/A |
When the C2000 intrinsic __rpt_mov_imm is used with a negative source operand, the compiler fails with a match error. This is because it was erroneously modeled as having an unsigned source operand. |
| CODEGEN-5791 |
C++ enum class with explicit type has some problems |
Fixed |
C2000_19.6.0.STS |
C2000_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 |
C2000_19.6.0.STS |
C2000_19.6.0.STS |
|
|
| CODEGEN-5739 |
C28x compiler manual incorrectly implies fields in a struct of type long, long long, double, long double, are only aligned o |
Fixed |
|
C2000_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 |
C2000_19.6.0.STS |
C2000_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 |
C2000_19.6.0.STS |
C2000_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 |
C2000_19.6.0.STS |
C2000_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-5119 |
Using #pragma RETAIN does not keep a static file level variable |
Fixed |
C2000_19.6.0.STS |
C2000_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 |
|
C2000_19.6.0.STS |
|
|
| SDSCM00052006 |
ltoa definition conflicts with quasi-standard ltoa |
Fixed |
|
C2000_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. |
