ID |
Summary |
State |
Reported In Release |
Target Release |
Workaround |
Release Notes |
CODEGEN-2060 |
Even though option --buffer_diagnostics is not used, compiler issues diagnostic that says it is deprecated |
Fixed |
|
C2000_17.3.0.STS |
None |
The --buffer_diagnostics compiler option was deprecated as of MCU compilers v16.6.0.STS because this setting became the default behavior for the compiler. However, the option was passed to the linker and the linker issued a remark stating the option was deprecated. |
CODEGEN-2053 |
Compiler incorrectly reorders struct assign for small, volatile structs with bit-fields |
Fixed |
|
C2000_17.3.0.STS |
Use optimization level 0 or off (option --opt_level) |
For a very specific optimization, the optimizer may drop a volatile qualifier from a struct assignment. In some cases, the compiler may later perform an incorrect optimization, most commonly incorrectly reordering volatile assignments.
This bug can only happen in a function compiled with optimization level 1 or higher which contains both of the following: 1) A struct assign where the destination is volatile, and the source is a known constant, and the struct contains a bit-field, and the struct is of size "int" or smaller. 2) Any bit-field access (read or write) other than as part of a struct assign or initialization expression. That is, the name of the bit-field is present in the access expression. Note that the optimizer can create this situation by inlining functions, so 1 and 2 might be in different functions in the source code.
Consider a tree x = y where x and y are of type struct S. If the value of y is known at compile time (e.g. a const value), the optimizer will try to turn the struct constant into an integer constant (possibly combining bit-fields) and rewrite the tree to look like this: "(unsigned *)x = 32;" However, if y is volatile, that should be "*(volatile unsigned *)x = 32;" Because the access is not volatile, instruction scheduling could cause this instruction to drift past nearby volatile accesses. |
CODEGEN-2050 |
Use of -o4 causes linker XML map file to have missing input_file entries |
Fixed |
|
C2000_17.3.0.STS |
|
|
CODEGEN-1976 |
Value of __cplusplus is wrong |
Fixed |
|
C2000_17.3.0.STS |
If possible, use the -ps or --strict_ansi options. This mode will use the strict definition of __cplusplus, which is 199711L. |
Our parser mimicked G++ behavior for the value of this macro in relaxed ANSI mode. This reproduced a bug in G++ versions v.4.7 and v.4.3 that has since been fixed. |
CODEGEN-1974 |
Remove --symdebug:coff from the compiler manual |
Accepted |
|
C2000_17.3.0.STS |
|
|
CODEGEN-1710 |
Illegal instruction selection for __byte_peripheral_32 on FPU32 |
Fixed |
|
C2000_17.3.0.STS |
Try a lower level of optimization. For our test case, optimization levels lower than 3 did not expose the bug. However, this workaround may not help for all test cases. |
Although byte peripheral types are integral, when FPU32 device support is enabled, the compiler might store 32-bit integral values in floating point registers when CPU registers are unavailable. The compiler erroneously generates a MOVL instruction instead of a MOV32 instruction for moving 32-bit byte peripheral data between floating point registers and byte peripheral memory, if this data gets assigned to a floating point register. |
CODEGEN-1705 |
Compiler documentation and RTS disagree on function names _TI_start_pprof_collection and _TI_stop_pprof_collection |
Fixed |
|
C2000_16.12.0.STS |
|
|
SDSCM00052878 |
Documentation error: #pragma pack should be lower case |
Fixed |
|
C2000_16.12.0.STS |
|
|
CODEGEN-1329 |
Lower diagnostic about redefined opcode to a warning, when a compiler intrinsic is redefined |
Fixed |
|
C2000_17.3.0.STS |
Remove the #define or do not include the header file in assembly files. |
When a header file attempting to redefine an opcode name is included in assembly files, the assembler issues an error because it is not legal to redefine an opcode name. While this behavior is correct, it causes programs to fail to compile when some C2000 header files are included in assembly files due to the "#define eallow ..." in the header files. |