| ID |
Summary |
State |
Reported In Release |
Target Release |
Workaround |
Release Notes |
| CODEGEN-4926 |
Packed structures generate unnecessary code on PRU |
Fixed |
|
PRU_2.3.0 |
Don't use the packed attribute for PRU. |
The use of the packed attribute on PRU should not result in any different code since PRU has native unaligned access. However, unnecessary code is being generated. |
| CODEGEN-4832 |
Compiler manual mistakenly states #pragma pack is supported |
Fixed |
PRU_2.3.0 |
PRU_2.3.0 |
|
|
| CODEGEN-4791 |
Structure field reference directly from function call causes INTERNAL ERROR |
Fixed |
|
PRU_2.3.0 |
Compile with any value of --opt_level except "off".
Or, given the expression f().x, change it to "t=f(); t.x"; in other word, capture the struct returned from the function call in a variable, and make the field reference from that variable instead of directly from the function call. |
Compiling an expression like f().x -- a function call immediately used to make a structure field reference -- can cause the compiler to abort with INTERNAL ERROR. Any use of the optimiser, or a simple code rearrangement, avoids the problem. |
| CODEGEN-4678 |
Incorrect error due to typedef of very large object |
Fixed |
PRU_2.3.0 |
PRU_2.3.0 |
As a workaround, remove the typedef. Where the typedef was used, instead use the type the typedef refers to. |
The TI compiler infrastructure is incapable of handling user-declared objects above a certain size, because it mistakenly truncates the size of very large objects. Formerly, this resulted in quiet corruption, which was defect CODEGEN-449. Now that CODEGEN-449 is fixed, the compiler will emit an error if the user attempts to create a type larger than the tool can handle. However, this error check is not quite right for typedefs. A typedef for a very large object that is still within the compiler's limit may cause the parser to mistakenly emit an error that the object is greater than the maximum supported size. |
| CODEGEN-4643 |
Documentation incorrectly lists __builtin_sqrt as being supported |
Fixed |
|
PRU_2.3.0 |
|
|
| CODEGEN-4638 |
When shift counts are higher than 32, compiler sometimes optimizes to an incorrect shift count |
Fixed |
|
PRU_2.3.0 |
Turn off optimization by using optimization level off.
Otherwise, avoid a left-shift by a constant as an operand of the listed operations. However, compiler optimizations could interfere with this. Try keeping the shift count in a global variable instead of as a literal, or computing the shift separately into a variable (a global or volatile local) and doing the |, +, etc, on the variable. |
Left shifts by 32 or more, as an operand of +, -, &, |, or ^, (eg, ((X<<56) | (Y<<48))) may produce incorrect results. |
| CODEGEN-4605 |
Incompatible redeclaration error with -o4 when using anonymous unions |
Fixed |
|
PRU_2.3.0 |
Do not use anonymous structs or unions; give all struct members a name, even if it is never used. |
Anonymous structs and unions are a GCC extension. They are members of a parent structure and have no names. You access the elements inside them as if they were direct members of the parent class. If you have an anonymous struct or union inside a union and you use -O4 optimization, you may get the mistaken error "symbol so-and-so redeclared with incompatible type" at link time. This bug can only happen in COFF mode.
Essentially the same bug was previously fixed for EABI and was known as CODEGEN-1191. |
| CODEGEN-4576 |
hex --ascii option truncates address to 16 bits |
Fixed |
|
PRU_2.3.0 |
Use the hex converter from an earlier release |
When generating an "ASCII" format hex file, the hex converter would mistakenly truncate addresses to the lower 16 bits. |
| CODEGEN-4419 |
Compiler erroneously speculates indexed load from the stack |
Fixed |
|
PRU_2.3.0 |
Modify the source code of the offending function to make local variables "volatile." There's no obvious way to pre-determine that a function will suffer from this bug; you just have to wait for the bug to happen, look at the line number of the offending instruction (which will always be a load with indexed addressing with base register SP), and go to the function at that line number. Make every local variable in that function "volatile." If it's a C++ function, you may need to make the function "volatile." |
The compiler moves instructions from one block to another to increase parallelism. Usually this is done by predicating (adding a condition to) every instruction that is moved above a branch. However, in some cases, the compiler will "speculate" the instruction, which means removing the condition entirely. This is done when the instruction's side-effects are judged to be safe, such as load of a local variable. In the case that the instruction's condition would have been false, this load will be useless, but at least it will be safe, because the stack pointer (SP) is at a legal location, and there won't be a memory fault. However, when a local variable's value is read with an indexed expression, the index register is not necessarily speculated exactly when the load is, so the index register may have a garbage value. In this test case, the load was speculated, but the index register definition wasn't, so in the false branch, the computed address was garbage, and we would read a random memory address, causing a memory fault. (Even though SP was perfectly valid, the index register was garbage, so SP+index might point anywhere in memory.) |
| CODEGEN-4407 |
Not using const causes unexpected build error when calling std::sort |
Fixed |
|
PRU_2.3.0 |
Remove unnecessary const from helper in s__algo.c |
|
| CODEGEN-4182 |
Should ignore option --pending_instantiations when compiling C files |
Fixed |
|
PRU_2.3.0 |
If the user wishes to use the option --pending_instantiations, they must add this option individually to each C++ file. |
The compiler option --pending_instantiations only makes any sense when used with C++ code. It cannot have any effect on C code. Indeed, when passed as an option to a compilation of C code, the compiler will stop and emit an error, "pending instantiations option can be used only when compiling C++"
This is troublesome when trying to compile a mixture of C and C++ files in CCS. If the user wishes to use the option --pending_instantiations, they cannot just add this option to the global compiler options list; they must add this option individually to each C++ file. |
| CODEGEN-4180 |
PRU compiler fails to account for zero-sized struct passed in register as function argument |
Fixed |
|
PRU_2.3.0 |
|
If an empty struct is passed as a function argument, the caller function passes 0 in a register but the called function ignores the argument. This results in the subsequent argument being allocated to a different register than the one the caller used. Now, both caller and callee functions ignore zero-sized struct arguments. |
| CODEGEN-4178 |
Update PRU documentation to include that 24-bit structs are also passed in registers |
Fixed |
|
PRU_2.3.0 |
|
|
| CODEGEN-4113 |
Assembler computes wrong result for expression 0x232800 % 0x10000 |
Fixed |
|
PRU_2.3.0 |
In some instances, as in the original test case, the AND operator can be used instead, but that is not a general workaround. |
The modulo operator in the TI assembler, for releases made in mid-to-late 2016 and all of 2017, is unreliable. In some cases it will produce an incorrect answer. |
| CODEGEN-4078 |
LInker takes over 5 minutes to finish |
Fixed |
|
PRU_2.3.0 |
None. If the linker command file wants to be that specific about memory ranges, then the work has to be done, and the option to disable the work has its own bug. |
Linking may take excessively long when the linker command file specifically places a lot of variables at specific addresses, especially for C2000. The original report was placing more than 300 variables. The --no_placement_optimization option is not a workaround because it causes a linker crash. Both problems are fixed together. |
| CODEGEN-3931 |
Compiler crashes while handling 0 length array in zero sized struct |
Fixed |
|
PRU_2.3.0 |
None |
The compiler crashes while parsing a struct or class with zero-sized members in C++ mode. |
| CODEGEN-3923 |
DWARF CFI information lost due to microoptimizations |
Fixed |
|
PRU_2.3.0 |
No practical workaround. |
Some optimizations in the compiler would change instructions but fail to retain debugging directives attached to those instructions. This could impact the accuracy of the DWARF debugging information in various ways. |
| CODEGEN-3918 |
Writing multiple input sections in one line unexpectedly changes how input sections are combined into output sections |
Fixed |
|
PRU_2.3.0 |
Stick with separate lines, if there are subsection cases like this one that should be comprehended. |
In a linker command file, using a line like "hello.obj (.const, .far)" may link differently than two lines with one section each. The problem is that the single line is interpreted as the OR of the two sections, and the linker does not understand that the OR also encompasses any of their subsections. Two separate lines are analysed separately and completely. |
| CODEGEN-3794 |
False warning for MISRA 10.1/10.2 when commutative binary operands swapped |
Fixed |
|
PRU_2.3.0 |
|
In certain cases, the compiler could emit an unwarranted MISRA diagnostic about type conversion. This would occur when using a commutative binary arithmetic operator with mixed operand types. The compiler mistakenly compared one operand's type to the other type. It should have compared each type to the promoted type of the operation. |
| CODEGEN-3595 |
Stack usage under reports stack amount used because it fails to handle function aliases |
Fixed |
|
PRU_2.3.0 |
|
CCS Stack Assistant did not accurately track aliased functions-- functions whose definitions are represented by a different symbol name. Now, the alias function will be used to determine stack size correctly, and the aliased function call name will be replaced with its alias. Currently, the Stack Assistant GUI is not capable of showing both the aliased and alias function names for calls to aliased functions-- this will require a future update. |
| SDSCM00043877 |
Emit error message when objects of size 512MB or larger truncated |
Fixed |
|
PRU_2.3.0 |
N/A |
Due to an internal limitation, the code generation tools cannot presently allocate objects of size 512 MB or larger. When such objects are declared in the code, they were silently truncated and compilation continued without any diagnostics. |
