| ID |
Summary |
State |
Reported In Release |
Target Release |
Workaround |
Release Notes |
| CODEGEN-5317 |
Ternary (?:) expression with 0/1 result uses type of predicate, not result, when optimised |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.10.LTS |
Compile with -Ooff. |
An expression like "(p ? 1 : 0)" can be converted by the compiler into "(p != 0)". If the types of 1 and 0 are wider than int, and the expression is shifted left, as in "(p ? 1UL : 0UL) << 16", then the value shifted will be int instead of the wider type, and the overall value will be incorrect. |
| CODEGEN-5236 |
Register allocation failure |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.9.LTS |
No practical workaround |
The compiler may, in rare cases, allocate registers incorrectly. The most common symptom would be an internal error indicating that register allocation has failed. This problem has only been observed on C28x compiler version 8.1.3.LTS, but could occur for other ISAs. |
| CODEGEN-4959 |
Premature deallocation of VLA arrays |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.9.LTS |
Rewrite the code so that it does not use VLA |
The intent behind C99 variable-length arrays (VLA) is that they are allocated on the stack, and thus are deallocated when the call frame is inactivated (by returning, or by being discarded with longjmp). However, we don't support actually allocating them on the stack, so we use malloc/free to simulate this. This works fine if the function exits normally; the parser turns a VLA declaration into a call to __vla_alloc, and placing a __vla_dealloc just before the function exits. However, what do you do if a longjmp skips over the function exit? The implementation needs a way to detect that and clean up dead VLAs.
It does this by keeping track of the SP during the call to __vla_alloc. When either __vla_alloc or __vla_dealloc is called, it looks at its own SP and compares it to the stored SP for each of the allocated VLAs it knows about. For MSP430, the stack grows toward zero. If the SP for any of the known VLAs is less than the current function's SP, those VLAs were allocated by a call to __vla_alloc deeper in the call stack than the current function, and thus must be dead.
This fails when procedure abstraction (PA) is involved, because PA creates a tiny little function to contain the PA code. This tiny little function has a lesser SP than the calling function, so it looks like a call deeper in the call stack. If there are any calls to __vla_alloc in the PA code, and any calls to either __vla_alloc or __vla_dealloc left in the calling function, the latter will cause any VLAs allocated in the PA code to be freed prematurely.
|
| CODEGEN-4885 |
See MISRA diagnostics when compiling stdio.h |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.10.LTS |
none |
A program that includes <stdio.h> and checks for MISRA warnings may see some from stdio.h itself, which should not happen. |
| CODEGEN-4700 |
Incorrect diagnostic when using macro that comes from macro library |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.10.LTS |
Unpack all of the macro libraries and re-pack them into a single unified library, or rename all macros to names with less than 15 characters |
If you are using assembler macro libraries, and you have more than one library, and two or more of those libraries have macros with names that are longer than 15 characters, you may get an incorrect error message from the assembler saying "Bad archive entry" |
| CODEGEN-4678 |
Incorrect error due to typedef of very large object |
Fixed |
|
MSP430_16.9.8.LTS |
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-4638 |
When shift counts are higher than 32, compiler sometimes optimizes to an incorrect shift count |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.8.LTS |
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-4623 |
Compiler incorrectly optimizes away member functions which arise from explicit template instantiation |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.10.LTS |
Compiling at -o2 helps, but sacrifices some optimisation. Adding a FUNC_CANNOT_INLINE pragma may also help, if it isn't an automatically-defined function. |
Compiling at -o3 may not retain external symbols for functions that are completely inlined within the file but which are declared extern, when using versions of the compiler from before 2017 -- ie, C6000 8.2.x, C2000/MSP430/TMS470 16.9.x. |
| CODEGEN-4605 |
Incompatible redeclaration error with -o4 when using anonymous unions |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.8.LTS |
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-4600 |
Warning when using pragma RETAIN with attribute((noinit)) |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.9.LTS |
|
When using pragma RETAIN with attribute((noinit)) on the same symbol for an EABI target, a .clink directive is erroneously emitted in the assembly file, leading to a warning that the .CLINK directive is being ignored because the symbol already has .RETAIN specified. |
| CODEGEN-4514 |
stdint.h has wrong value of PTRDIFF_MAX under large data model |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.8.LTS |
Avoid using the macro PTRDIFF_MAX |
|
| CODEGEN-4419 |
Compiler erroneously speculates indexed load from the stack |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.8.LTS |
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 |
|
MSP430_16.9.8.LTS |
Remove unnecessary const from helper in s__algo.c |
|
| CODEGEN-4280 |
Using ULP advisor with C++ templates may cause the compiler to crash |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.7.LTS |
|
The compiler may crash when using ULP advisor on C++ code that contains templates |
| CODEGEN-4182 |
Should ignore option --pending_instantiations when compiling C files |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.8.LTS |
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-4113 |
Assembler computes wrong result for expression 0x232800 % 0x10000 |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.7.LTS |
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 |
MSP430_16.9.0.LTS |
MSP430_16.9.7.LTS |
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 |
MSP430_16.9.0.LTS |
MSP430_16.9.8.LTS |
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 |
MSP430_16.9.0.LTS |
MSP430_16.9.8.LTS |
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 |
MSP430_16.9.0.LTS |
MSP430_16.9.7.LTS |
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-3876 |
Code incorrectly removed from functions calling "naked" attribute functions |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.7.LTS |
|
The compiler supports the GCC attribute "naked," which means that a function shall not have prolog or epilog code. The idea is that this makes a blank function that the user may fill with assembly code.
The compiler also keeps track of the register usage behavior of previous functions in the same module, so that it can do some small optimizations like allocate caller-saved registers or eliminate unused code.
In this case, the compiler mistakenly assumed that a naked function did not use its input. The truth is that naked functions are essentially hand-coded assembly functions; while the compiler can assume they obey the C calling convention, the compiler can't know register behavior because it cannot parse the assembly instructions. |
| CODEGEN-3858 |
OFD gets DIE attribute offset wrong when using --dwarf_display=none,dinfo |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.7.LTS |
If you use --dwarf_display=none,dinfo, use --dwarf_display=none,dinfo,types instead |
You can use OFD to display the DWARF debugging information in your object files by using the option '--dwarf' (or -g). You can narrow the categories of DWARF information displayed by using the '--dwarf_display' option. If you use the option --dwarf_display=none,dinfo you will see the DWARF DIE objects in the .dwarf_info section, but you will not see any DW_AT_type attributes unless you also use the "types" flag. This is not a bug. However, when OFD skips a DW_AT_type attribute, it displays the offset of the skipped DW_AT_type for the next attribute instead of the next attribute's correct offset. |
| CODEGEN-3801 |
Linker crashes with INTERNAL ERROR (unhandled exception) |
Fixed |
MSP430_16.9.4.LTS |
MSP430_16.9.6.LTS |
|
The linker experiences a segmentation fault when there is a reference from a debug section to a symbol without a section (for example, an absolute symbol). |
| CODEGEN-3794 |
False warning for MISRA 10.1/10.2 when commutative binary operands swapped |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.7.LTS |
|
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-3650 |
Linker crashes when printing module list to map file |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.6.LTS |
Add linker option --mapfile_contents=all,nomodules |
When creating a linker map file, and a summary of modules is written to the linker map file, and the entry point is undefined, the linker may crash. |
| CODEGEN-3619 |
pragma triggers false MISRA-C:2004 19.1/A warning |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.7.LTS |
N/A |
Certain pragmas appearing prior to #include statements, such as #pragma RESET_MISRA, would cause MISRA warning 19.1/A to be issued:
MISRA-C:2004 19.1/A: #include statements in a file should only be preceded by other preprocessor directives or comments |
| CODEGEN-3617 |
gmtime incorrect when invoked in timezones east of GMT |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.6.LTS |
Set the timezone to 0 (UTC) until the fix is in place |
|
| CODEGEN-3597 |
ELF header field e_phoff should be 0 when no program header is present |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.6.LTS |
|
ELF header field e_phoff should be 0 when no program header is present, and ELF header field e_shoff should be 0 when no section headers are present. |
| CODEGEN-3595 |
Stack usage under reports stack amount used because it fails to handle function aliases |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.8.LTS |
|
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. |
| CODEGEN-3591 |
When using fill value, linker may crash or hang |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.6.LTS |
Upgrade to 17.6.0.STS or higher |
When using a fill value on a memory range, the linker may get into a corrupted state and either crash or enter an infinite loop. |
| CODEGEN-2424 |
Update mpu_init.c file for FR57xx family MPU in TI CGT |
Fixed |
MSP430_16.9.6.LTS |
MSP430_16.9.6.LTS |
Upgrade to MSP430 compiler version 17.9.0.STS, or 16.9.6.LTS, or 15.12.7.LTS.
Or rebuild your compiler RTS after adding below lines to mpu_init.c:
extern volatile unsigned char MPUCTL0_H;
Add below to the end of __mpu_init() routine definition:
MPUCTL0_H = 0x0; /* Lock MPU */ |
The current Run Time System (RTS) definition of __mpu_init() in mpu_init.c does not enable MPU protection after initialization. The RTS implementation only applies to FR57xx devices. |
| CODEGEN-2373 |
Internal linker error triggered by function alias |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.6.LTS |
|
Linker sometimes generates "Assertion failed" message and aborts. |
| CODEGEN-2286 |
palign(8) of .init_array messes up __TI_INITARRAY_Limit address |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.4.LTS |
In the linker command file, replace
.init_array > FLASH, palign(8), fill = 0xffffffff
with the following GROUP statement:
GROUP
{
.init_array
} > FLASH, palign(8)
The palign(8) on GROUP will ensure that any required padding is added after .init_array. However, both the size of .init_array and the value of __TI_INITARRAY_Limit remain unchanged. |
Applying palign(8) to .init_array caused __TI_INIT_ARRAY_Limit to be set to the end of .init_array including the padding. This broke RTS startup code responsible for calling constructors because the table of constructors now includes invalid data. This bug has been fixed and __TI_INIT_ARRAY_Limit is no longer affected by padding. |
| CODEGEN-2238 |
Compiler incorrectly emits MISRA 10.1 for function argument |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.6.LTS |
|
|
| CODEGEN-2143 |
Anonymous struct in union causes type merging failure at -O4 |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.4.LTS |
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. |
| CODEGEN-2119 |
Stack usage assistant call graph misses callee relationship for some direct calls |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.3.LTS |
|
The Object File Display utility failed to detect function callees when generating call graph information for functions that contain nested blocks. |
| CODEGEN-2113 |
Hex utility mishandles space in directory name of output file |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.4.LTS |
Use directory names without spaces for output files. |
The hex utility did not correctly handle spaces in output directory and file names. |
| CODEGEN-2098 |
Temp filename collisions on Windows with many parallel invocations |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.3.LTS |
|
In some cases with a large number of compilations in parallel on Windows, the compiler could create temporary files with colliding names, resulting in strange compilation failures. |
| CODEGEN-2060 |
Even though option --buffer_diagnostics is not used, compiler issues diagnostic that says it is deprecated |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.3.LTS |
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 |
MSP430_16.9.0.LTS |
MSP430_16.9.2.LTS |
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 |
MSP430_16.9.0.LTS |
MSP430_16.9.2.LTS |
|
|
| CODEGEN-2047 |
CMSIS Core v5 is not compliant with TI ARM Compiler |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.2.LTS |
The __INLINE macro in the TI compiler RTS linkage.h is no longer used and can be removed. |
CMSIS v5 defines the macro __INLINE, which interferes with the TI compiler RTS definition of the same macro in linkage.h. |
| CODEGEN-2025 |
Linker crash message incorrectly suggests submitting a preprocessed file |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.3.LTS |
|
|
| CODEGEN-2010 |
Decomp error involving packed class |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.2.LTS |
|
Fixed an issue that could result in a "Decomposition error" abort of the compiler. |
| CODEGEN-1995 |
Pointer math addend incorrectly truncated to ptrdiff_t on MSP430 |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.6.LTS |
|
The compiler was incorrectly handling array index expressions where the value of the index expression did not fit in ptrdiff_t. In some cases, the compiler would truncate the value to ptrdiff_t, changing the value. This bug can only occur in restricted or large data models.
This fix can affect the compiler's ability to optimize code. Importantly, for restricted data model, the compiler can no longer assume that pointer index expressions can use indexed addressing mode. Indexed addressing mode has a 16-bit signed offset, which may not be big enough to hold the value of the index expression. In this case, the pointer index expression must be carried out as pointer arithmetic followed by a non-indexed addressing mode, which requires more instructions and thus more cycles. This means that in restricted data model, there may be a performance loss when upgrading to this version.
Whether this loss occurs, and how big the loss is, depends greatly on whether your program uses pointer index expressions in critical loop bodies. We have observed that most of our benchmarks are unaffected, but we have some benchmarks that degraded after this fix. |
| CODEGEN-1979 |
Statements before declarations with no white space (aggravated by macros) may cause incorrect parser error |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.6.LTS |
Do not start any statement in the left-most column
Rearrange your code so that there are no statements before declarations. |
C99 and C++ allow statements before declarations in functions. This is not allowed by the C89 language, but as an extension, the TI compiler allows such statements in relaxed mode. However, in certain circumstances, the compiler may emit the 'error: expected "}"' for otherwise legal code which has statements before declarations.
This problem can only occur in relaxed C89 mode (which is the default mode), and 1) you have a function with statements that start in the left-most column, or 2) you use macros where the macro body contains C code with statements before declarations. |
| CODEGEN-1976 |
Value of __cplusplus is wrong |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.2.LTS |
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-1703 |
Designated initializer plus struct hack hangs compiler |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.1.LTS |
Avoiding using string constants to initialize objects with flexible array members. Instead, use a brace-initialized array. For example:
struct { int a; char b[]; } mystruct = {0, {'h', 'e', 'l', 'l', 'o'} }; |
Fixed a compiler hang caused by initializing flexible array members with string constants.
struct {int a; char b[]; } mystruct = {0, "hello"} /* Would cause the compiler to hang and/or crash */ |
| CODEGEN-1656 |
Using --gen_profile_info does not work with -o4 |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.4.LTS |
Lower the optimization level to -o3. |
Previously, link time optimization failed when profiling options --gen_profile_info and use_profile_info were specified in combination with the --opt_level=4 option. The errors were because profiling options were not supported when used in combination with --opt_level=4.
Application profiling during whole program optimization is now supported. Profiling options --gen_profile_info and --use_profile_info may now be combined with --opt_level=4. |
| CODEGEN-1649 |
Warning "INLINE recursion limit exceeded" during RTS build |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.0.LTS |
None, for the automatic library builds. Elsewhere, one can use the hidden --inline_recursion_limit option to increase the limit above the default 10. |
The compiler may emit the warning "INLINE recursion limit exceeded," but there is no way to suppress the warning, and it really isn't useful for the typical compiler user. These changes remove the warning. |
| CODEGEN-1640 |
MISRA 19.1 misreported: #include statements should only be preceded by other preprocessor directives |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.1.LTS |
No practical workaround |
|
| CODEGEN-1639 |
MISRA-C:2004 17.6/R false positive when assigning local struct member to static struct member |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.4.LTS |
|
|
| CODEGEN-1634 |
MISRA 7.1 misreported: octal tokens in token paste |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.1.LTS |
No practical workaround |
|
| CODEGEN-1632 |
MISRA 15.2 misreported: switch clause unconditional break |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.1.LTS |
Put an explicit break at the end of the compound statement |
|
| CODEGEN-1545 |
MSP430 ULP Advisor mistakenly says to use type int16_t, when it means uint16_t |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.3.LTS |
|
|
| CODEGEN-1517 |
#pragma FUNCTION_OPTIONS meaningless unless at least -o0 is used |
Fixed |
|
MSP430_16.9.0.LTS |
|
|
| CODEGEN-1433 |
MSP430 assembler may internal error for symbol defined differently in each pass when forward referencing a label |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.1.LTS |
Do not use a forward reference of a label. |
A forward reference of a label by an instruction that may use the constant generator (such as a move) in assembly may cause the position of a later label to be "defined differently in each pass," an internal error in the assembler.
|
| CODEGEN-1417 |
User error in _symval call causes compiler to issue INTERNAL ERROR: no match for ICALL |
Fixed |
|
MSP430_16.9.0.LTS |
|
|
| SDSCM00052904 |
Unsigned array index not truncated properly in array indexing expression |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.2.LTS |
None |
An unsigned integer multiplication used in an array indexing expression was erroneously optimized into instructions performed in 20 bits instead of 16 bits, thereby failing to truncate an overflowed value into zero. |
| CODEGEN-1333 |
Structure assignment causes compiler to fail with INTERNAL ERROR: Decomposition error |
Fixed |
|
MSP430_16.9.0.LTS |
Replace struct assignments involving packed structures with a memcpy() call to copy the contents of the RHS of the struct assign to the LHS. |
|
| CODEGEN-1297 |
Incorrectly issues ULP 8.1 diagnostic |
Fixed |
|
MSP430_16.9.1.LTS |
N/A. |
The compiler throws an invalid ULP 8.1 diagnostic in the case below:
% type try1.c
void test2(char buffer[5])
{ buffer[0] = 'A'; }
void test(void)
{
char buf[5] =
{ 0 }
;
test2(buf);
}
% cl430 --advice:power try1.c
"try1.c", line 8: remark: (ULP 8.1) variable "buf" is used as a constant. Recommend declaring variable as either 'static const' or 'const' |
| CODEGEN-1292 |
MSP --near_data revert linktime optization fix from CQ52683 due to code size degradations |
Fixed |
|
MSP430_16.9.0.LTS |
Ensure that the same --near_data option is used for all object files and libraries in the link. |
A relocation error may occur during link time optimization if --near_data has been specified with different values for different translation units. Earlier change in SDSCM00052683 introduced code size degradations and has been reverted. |
| SDSCM00040386 |
Remove -olength option from hex utility's help summary and Users Guides |
Fixed |
MSP430_16.9.0.LTS |
MSP430_16.9.0.LTS |
|
|
| SDSCM00052153 |
Remove compiler option --gen_func_subsections from MSP430 compiler user's guide |
Fixed |
|
MSP430_16.9.0.LTS |
|
The --gen_func_subsections option should be removed from the MSP430 compiler user guide. Function subsections are always generated for MSP430. |
