| CODEGEN-6682 |
Combination of many include paths and .cdecls causes assembler to segmentation fault |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.4.LTS |
Use no more than 99 total include paths plus .cdecls directives. |
Invoking the assembler with 100 or more combined --include options and .cdecls directives can cause it to crash. |
| CODEGEN-6501 |
memory allocation functions do not robustly handle case of --heap_size=0 |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.4.LTS |
|
It is possible to set the size of the allocation heap to a total size (such as zero) that is too small to handle any allocations. The C library's dynamic memory allocation routines (e.g. malloc) did not gracefully handle allocations in this case. These functions might crash, or might scribble on unrelated program memory, or might return successfully with a bogus pointer, in which case the caller would likely proceed to write through the bogus pointer and scribble on arbitrary memory. |
| CODEGEN-6289 |
Pointer to VLA 2D array computation in IF condition is double-adjusted and garbled |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.3.LTS |
Given "if (p[i][j])", moving the access into a temp with "T = p[i][j]; if (T)" is the simplest workaround. Since the bug happens early in compilation, optimisation level doesn't matter.
Recasting the IF as a quest/colon, if feasible, is also a workaround. |
A variable-length-array access for an array of at least two dimensions, if used in the predicate of an IF statement, may be mishandled and refer to an incorrect element, possibly outside the array. |
| CODEGEN-6244 |
Wrong version of __generic used under --c11 |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.3.LTS |
The corrections are in the RTS headers math.h and cgmath.h. These files can be modified and the RTS libraries rebuilt. |
Type generic math functions such as isfinite will fail when the --c11 compiler option is used with a failure message about the __generic macro:
error: too many arguments in invocation of macro "__generic". |
| CODEGEN-6135 |
Using --opt_level=4 with inconsistent --near_data can cause relocation overflow error |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.3.LTS |
Make sure that all files are compiled with --near_data=none when making a global variable that must use large data pointers, or else use -O3 instead of -O4. |
This test case has a large global array, which requires --near_data=none, and indeed the files that reference it have that option. However, another file (mpu_init.c) was compiled with --near_data=globals. Due to a bug in the compiler, all the --near_data options are merged at -O4 into a single --near_data that applies to all the recompiled files, and the merged value is "globals."
With --near_data=globals, short pointers are used for the large global array, which can't work and causes a relocation-overflow error. The solution to the compiler bug is to stick with the original --near_data for each file. The workaround for this case is to make sure all files are compiled with --near_data=none, or else to use -O3 instead of -O4. |
| CODEGEN-6132 |
pdd tool fails when program includes unused file |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.3.LTS |
Leaving the sys_pcr.obj file out of the link command works, but it's hard to tell that that's the problem file. |
The profile decoder, armpdd or pdd2000 or pdd430 or pdd6x, may fail when the program on which it is called includes a file whose functions are not included in the link.
In the test case given, the file sys_pcr.obj contains functions that are not called anywhere and therefore are not included in the .out file. However, due to some quirk that we have not yet isolated, the debug info for sys_pcr.obj *is* included. When the profile decoder collects its data, it uses the debug info to locate it; the faulty extra debug info points to invalid locations, causing the warnings.
We don't know yet whether the problem is with a single excluded function, more than one, or a whole file whose functions aren't included. What we have done is to make the profile decoder recognise and ignore the bogus debug info. |
| CODEGEN-6130 |
deque push_back of structure larger than 64-bytes tries to write to invalid memory location |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.3.LTS |
1. Keep deque elements to 64 bytes or less.
2. Edit include/libcxx/deque and change the definition of "value" in "__deque_block_size" to an expression that is never less than 2.
3. Use a different data structure. |
The implementation of std::deque in libc++ has a bug when the block size is 1. The stock version never uses a size that small and never exposes the bug. The TI version, used for ARM and MSP430 since 18.1.1.LTS and C6000 since 8.3.0, uses a formula that makes the block size 1 when the deque's elements are 65 bytes or larger. (Our parts are generally used in embedded situations and often have limited memory.) |
| CODEGEN-6004 |
OFD erroneously prints 0x<decimal> where hex was intended |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.2.LTS |
Update the OFD binary |
When using OFD to view the DWARF debug information in an object file, OFD will incorrectly format what should be a hexadecimal number as 0x followed by the decimal value. This affects two contexts: When printing the FORM_ref4 offset of an attribute (such as DW_AT_type) DIE appearing in the same .debug_info section, and when printing the CIE ID. |
| CODEGEN-5986 |
Compiler may crash when auto as return type of uninstantiated member function in template class resolves to template paramet |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.3.LTS |
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 |
MSP430_18.12.0.LTS |
MSP430_18.12.2.LTS |
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-5905 |
Linker command file option --define with pathname with many directory components leads to error: "source line too long" |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.2.LTS |
|
|
| CODEGEN-5843 |
Use of --check_misra=14.10 causes non-MISRA related warning to be emitted |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.3.LTS |
No direct workaround. The warning can be suppressed by the usual methods, or corrected as described in the report. |
If a local variable's address is taken before the variable is initialised, there will usually not be a warning with default settings. However, if any --check_misra option is used, the compiler will issue a used-before-set warning for the variable. |
| CODEGEN-5809 |
MSP430 compiler may intermittently crash when using hardware multiply |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.2.LTS |
Don't use the hardware multiply, ie, --use_hw_mpy=none. |
The MSP430 compiler may crash when using the hardware multiply, eg, --use_hw_mpy=F5. There is not a simple code sequence that triggers the problem; the right combination of instructions and codegen passes may access outside the bounds of an internal compiler structure, and that may trigger a crash. |
| CODEGEN-5773 |
--emit_references:file causes an internal error on Mac |
Fixed |
MSP430_18.12.1.LTS |
MSP430_18.12.1.LTS |
|
|
| CODEGEN-5708 |
Parser crashes when zero-initializing unused local variable |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.1.LTS |
Remove the unused variable. |
The parser will crash if the source code attempts to create a local class, struct, union, or array variable that is never used and is zero-initialized. A local variable is zero-initialized if it has a partially specified initializer expression or if it is a class which requires zero-initialization. |
| CODEGEN-5674 |
Under -o4, compiler may assume a global variable is constant, if it's only set in files containing inline asm() |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.3.LTS |
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-5623 |
Makefile dependence generation (--preproc_dependency) should quote spaces in filenames |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.2.LTS |
Rename the files so that they don't have spaces in the names. |
The parser generates makefile dependencies with the --preproc_dependency option. However, if any filename has a space in its name, the makefile dependencies will not be formatted in a way that can be parsed by make. |
| CODEGEN-5574 |
Loop controlled by unsigned char counter iterates more than 255 times |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.2.LTS |
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-5563 |
Checking for MISRA rule 20.1 causes macro redefinition to be ignored |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.3.LTS |
None. To detect redefined macros that aren't predefined, --check_misra=20.1 must not be in the compilation options. |
The --check_misra=20.1 option, which looks for redefined reserved identifiers such as predefined macros, will accidentally suppress warnings about redefinitions of macros that *aren't* predefined. Since those aren't included in the group that 20.1 tests for, no warning will be issued at all. |
| CODEGEN-5558 |
C++14 enum class values in a switch causes no match for MINUS |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.1.LTS |
|
|
| CODEGEN-5533 |
Loop with Cortex-R, -mf3, and DWARF debug leads to assembler error "defined differently in each pass" |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.3.LTS |
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-5527 |
Local structure initialization is incorrectly optimized away |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.2.LTS |
None better than the one given in the description. |
A program that saves the address of a variable in an initialised local struct, but does not use the variable directly, may lose the part of the struct that saves the address. |
| CODEGEN-5511 |
Compilers other than C6000 mistakenly support option --legacy |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.2.LTS |
|
|
| CODEGEN-5486 |
Global constexpr class errors out when assigning to member data |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.2.LTS |
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-5403 |
Improve documentation in Compiler Guides for PERSISTENT and NOINIT pragmas |
Fixed |
|
MSP430_18.12.0.LTS |
|
|
| CODEGEN-5333 |
Emit error message when referenced placeholder routine not selected during specialization |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.4.LTS |
|
Boot routine specialization support was added in CGT v18.1.0.LTS. In the case that a specialized boot routine was intended to be used but no suitable routines were found, the linker would fail to issue an error and complete linking the code without the required routine. The program would then fail during run time. Now the linker will issue an error. |
| CODEGEN-5317 |
Ternary (?:) expression with 0/1 result uses type of predicate, not result, when optimised |
Fixed |
|
MSP430_18.12.0.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-5305 |
Manual incorrectly states .bss, and not .data, is initialized by .cinit |
Fixed |
|
MSP430_18.12.0.LTS |
|
|
| CODEGEN-5187 |
Compiler mishandles signed right-shifts by 16 on targets with 16-bit ints |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.0.LTS |
None known. |
For MSP430 and C2000, a right-shift of a signed long (ie, 32-bit) expression by 16 -- X>>16 -- will be compiled as an unsigned right-shift, which can lead to incorrect sign-extensions in the result. |
| CODEGEN-5119 |
Using #pragma RETAIN does not keep a static file level variable |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.2.LTS |
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 |
MSP430_18.12.0.LTS |
MSP430_18.12.2.LTS |
|
|
| CODEGEN-4885 |
See MISRA diagnostics when compiling stdio.h |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.0.LTS |
none |
A program that includes <stdio.h> and checks for MISRA warnings may see some from stdio.h itself, which should not happen. |
| SDSCM00050131 |
Local struct with non-constant initializer treated as static scope variable |
Fixed |
MSP430_18.12.0.LTS |
MSP430_18.12.1.LTS |
Completely specify every aggregate member in the initializer, or do not provide an initializer at all and instead populate each field with a statement. |
Function local non-static aggregate (array or struct) variables which are initialized to zero, or with an initializer that incompletely specifies all of the aggregate members, will be converted to static scope (global) objects. This is wrong; each time the function is entered, there should be a fresh copy of the variable. |
