Closed Defects in Release

ID Summary State Reported In Release Target Release Workaround Release Notes
CODEGEN-6603 Compiler fails with Internal Error: Constant Table Error Fixed ARM_18.1.0.LTS ARM_18.1.7.LTS Add optimisation (-o0, -o1, ...). Use --embedded_constants=off. Using --symdebug:none may help, but will impair debugging. Compiling a file containing long functions with lots of constants -- in this case, one function has 2000 lines and another has almost 13,000 -- without optimisation may abort with a "constant table error" message. The compiler is trying to place constants in among the instructions, which usually leads to more efficient code for ARM Cortex devices, but was unable to do so. Turning off embedded constants inhibits the whole pass, while compiling with optimisation reduces the number of constants.
CODEGEN-6581 Optimizer fails with segmentation fault Fixed ARM_18.1.0.LTS ARM_18.1.7.LTS No simple workaround. If there's a way to restructure the code to avoid template parameter packs, or at least to avoid passing them as arguments to calls, try that. This particular test case will not crash with -O2 or -O3, though it will with -O0 and -O1. The --disable_inlining option will avoid the problem, but of course affects performance. When compiling C++ code that uses template parameter packs, especially if those parameter packs are passed as arguments to calls within the template functions, the optimiser may crash.
CODEGEN-6362 Compiler may reassociate mixed-width addition and lose implicit wider-than-int conversion Fixed ARM_18.1.0.LTS ARM_18.1.7.LTS The given case does "carry += *x++; carry += *y++;". One workaround is to rewrite that as "carry = (carry + *x++) + *y++;". The parens force the first addition to be 64-bit, which in turn forces the second to be 64-bit, while preventing the reassociation that allowed the erroneous 32-bit addition. The compiler is allowed to combine and reassociate additions and other associative operations. However, some combinations of mixed-width operations, where the desired type is wider than int, may be reassociated incorrectly in a way that allows the operation in a narrow type than intended. In this case, it's expressed as "c += X; c += Y", where X and Y are int32_t and c is int64_t. The compiler is turning that into "c += X + Y", which adds X and Y as int32_t and thus doesn't keep the 33rd bit.
CODEGEN-6289 Pointer to VLA 2D array computation in IF condition is double-adjusted and garbled Fixed ARM_18.1.0.LTS ARM_18.1.7.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-6132 pdd tool fails when program includes unused file Fixed ARM_18.1.0.LTS ARM_18.1.7.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 ARM_18.1.1.LTS ARM_18.1.7.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-5843 Use of --check_misra=14.10 causes non-MISRA related warning to be emitted Fixed ARM_18.1.0.LTS ARM_18.1.7.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-5563 Checking for MISRA rule 20.1 causes macro redefinition to be ignored Fixed ARM_18.1.0.LTS ARM_18.1.7.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-5533 Loop with Cortex-R, -mf3, and DWARF debug leads to assembler error "defined differently in each pass" Fixed ARM_18.1.0.LTS ARM_18.1.7.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-5333 Emit error message when referenced placeholder routine not selected during specialization Fixed ARM_18.1.0.LTS ARM_18.1.7.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-6046 Header file arm_acle.h is missing the matching brace for extern "C" { Fixed ARM_18.1.5.LTS ARM_18.1.6.LTS
CODEGEN-6031 Expressions/Variable view is not properly resolving some C++ symbols properly Fixed ARM_18.1.1.LTS ARM_18.1.6.LTS None. Some variables in the CCS Expressions/Variables view are not demangled correctly. The problem is that the compiler and CCS have different versions of the demangling code, which behave somewhat differently. CCS needs to be updated.
CODEGEN-5986 Compiler may crash when auto as return type of uninstantiated member function in template class resolves to template paramet Fixed ARM_18.1.0.LTS ARM_18.1.6.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 ARM_18.1.0.LTS ARM_18.1.6.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-5924 ARM compiler error with 64-bit constant decomposed into 2 16-bit constants Fixed ARM_18.1.0.LTS ARM_18.1.6.LTS One workaround is to change the negative constant in the assembly file to its unsigned equivalent and recompile the assembly file. In this case, the option to keep the assembly file must be used. The negative constant causing the compiler error should be converted to its binary representation, and that representation converted to an unsigned number. A load of a 64-bit source constant such as the following example, which can be broken into 2 16-bit constants for bits 0-15 and 32-47 (bits 16-31 and 48-64 are 0), may incorrectly emit a negative constant in the assembly file, causing the assembler to issue an error. For example: unsigned long long x = 0xca0600006274;
CODEGEN-5905 Linker command file option --define with pathname with many directory components leads to error: "source line too long" Fixed ARM_18.1.0.LTS ARM_18.1.6.LTS
CODEGEN-5791 C++ enum class with explicit type has some problems Fixed ARM_18.1.0.LTS ARM_18.1.6.LTS 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-5775 Compiler fails with diagnostic: INTERNAL ERROR: no match for PLUS Fixed ARM_18.1.0.LTS ARM_18.1.6.LTS Saving the division computation that is the input to the addition in a temporary variable, and then using the temporary variable as the input to the addition avoids the problem. For example: unsigned int x; long long y; long long tmp = (long long)x / (long long)1000; long long res = y + tmp; This bug occurred when an operand to a 64-bit division was an unsigned 32-bit type cast to 64-bits, and the division was an input of an addition. For example: unsigned int x; long long y; long long res = y + ((long long)x / (long long)1000);
CODEGEN-5674 Under -o4, compiler may assume a global variable is constant, if it's only set in files containing inline asm() Fixed ARM_18.1.0.LTS ARM_18.1.6.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 ARM_18.1.0.LTS ARM_18.1.6.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 ARM_18.1.0.LTS ARM_18.1.6.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-5558 C++14 enum class values in a switch causes no match for MINUS Fixed ARM_18.1.0.LTS ARM_18.1.5.LTS
CODEGEN-5527 Local structure initialization is incorrectly optimized away Fixed ARM_18.1.0.LTS ARM_18.1.6.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 ARM_18.1.0.LTS ARM_18.1.6.LTS
CODEGEN-5486 Global constexpr class errors out when assigning to member data Fixed ARM_18.1.0.LTS ARM_18.1.6.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-5387 Loop with early exit may peel incorrectly when unrolling (as with -mf3 or above) Fixed ARM_18.1.0.LTS ARM_18.1.5.LTS Add "#pragma UNROLL(1)" to the affected loop to inhibit unrolling, or compile with --opt_for_speed=2 or lower which inhibits unrolling of all loops. The compiler may unroll loops to speed them up. If it doesn't know the exact trip count, it needs to "peel" some iterations to make sure it does the extras if they don't fit exactly into the unrolled loop. If the loop has an early exit -- in this case, it looks roughly like while (flen-- && isdigit(*s)) ... -- then there's a problem, because when the unrolled loop finishes, it could be because it's done, or it could be because isdigit(*s) returned false. If the unrolled part is done, we need to do the peeled part, but if isdigit() returned false, we don't, and the logic isn't ready for that conundrum and does the wrong thing.
CODEGEN-5305 Manual incorrectly states .bss, and not .data, is initialized by .cinit Fixed ARM_18.1.3.LTS ARM_18.12.0.LTS
CODEGEN-5236 Register allocation failure Fixed ARM_18.1.0.LTS ARM_18.1.4.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-5127 Linker fails with INTERNAL ERROR: no match for COMMA Fixed ARM_18.1.0.LTS ARM_18.1.4.LTS Compile with --opt_level=3, or ensure that all constituent files are either compiled with --neon or without --neon. Combining object files compiled with --neon and without --neon in a --opt_level=4 final compilation, even if they're all compiled with -mv7a8, can cause a compiler abort.
CODEGEN-5119 Using #pragma RETAIN does not keep a static file level variable Fixed ARM_18.1.0.LTS ARM_18.1.6.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-5033 Functions in <string> incorrectly return NULL Fixed ARM_18.1.0.LTS ARM_18.1.4.LTS Ignore or suppress the warning. char_traits<char>::find() and char_traits<wchar_t>::find() return char* and wchar_t*, respectively. In our __string file (included by <string>), they are written to return NULL, which is (void*)0 and not the same type as the declaration, thus producing a warning. We have updated the file to make them return 0, which fixes the warnings.
CODEGEN-5032 Loop over array, preceded by shuffle of the array using scalar temp repeatedly, may produce incorrect results Fixed ARM_18.1.0.LTS ARM_18.1.5.LTS The test case uses the same temp, nTemp, repeatedly in the shuffle function. Using different temps for each assignment will avoid the problem. Using "#pragma UNROLL(1)" to inhibit unrolling of the affected loops may also avoid the problem. The problem case looks something like x = a[0] a[1] = x x = a[2] a[3] = x for (i = 0; i < N; i++) { a[i] = ... ... a[i] ... } It shuffles data in an array a[] using the scalar x, then loops over array a[]. This particular arrangement, with the right optimisations, will do the wrong thing with the shuffle code. The wrong thing is part of optimising the loop, so both parts are required for there to be a problem. A workaround is to use a separate scalar variable for each assignment in the shuffle, ie, "x1 = a[0]; a[1] = x1" and "x2 = a[2]; a[3] = x2".
CODEGEN-4931 Applying __attribute__((used)) to static variable does not work Fixed ARM_18.1.0.LTS ARM_18.1.6.LTS
CODEGEN-4912 Including stddef.h may disable MISRA diagnostics Fixed ARM_18.1.0.LTS ARM_18.1.4.LTS Add "#pragma diag_pop" after the inclusion of these files. SInce they're sometimes included from other system include files, it may take some digging to realise that this is necessary. Two include files -- stddef.h and string.h -- each lacked one diag_pop pragma to match the diag_push pragma, which meant that including those files would inadvertently disable certain MISRA warnings.
CODEGEN-4885 See MISRA diagnostics when compiling stdio.h Fixed ARM_18.1.0.LTS ARM_18.1.5.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 ARM_18.1.0.LTS ARM_18.1.5.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-4692 __delay_cycles intrinsic not available when building for Cortex-R5 Fixed ARM_18.1.1.LTS ARM_18.1.3.LTS Use Cortex-R4 instead (--silicon_version=7R4). TI ARM compiler version 18.1.1.LTS does not recognize the intrinsic __delay_cycles when compiling specifically for Cortex-R5.
CODEGEN-4678 Incorrect error due to typedef of very large object Fixed ARM_18.1.0.LTS ARM_18.1.3.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-4668 Macro with temp label causes assembler to crash Fixed ARM_18.1.0.LTS ARM_18.1.3.LTS The problem will not occur without macro labels. If labels are required, no workaround is known. The assembler may crash or report a memory misuse when using an assembly macro containing a label, if the label appears in an instruction in a position that requires extra lookahead to parse. The original example is a register name followed by a comma and a label use; for that assembler, the thing following the comma might be a shift specifier, so it requires expanding the macro label. That extra step frees some memory that it shouldn't, causing the problem.
CODEGEN-4655 DWARF type incorrect for char function formal parameter Fixed ARM_18.1.0.LTS ARM_18.1.3.LTS The compiler does not emit the correct type for function formal parameters that have integer type smaller than int. This only matters when trying to inspect the formal parameters before the prolog has executed.
CODEGEN-4638 When shift counts are higher than 32, compiler sometimes optimizes to an incorrect shift count Fixed ARM_18.1.0.LTS ARM_18.1.2.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-4634 Use of stdarg.h va_start macro causes a write to the wrong local variable Fixed ARM_18.1.0.LTS ARM_18.1.4.LTS The test case for codegen-4634 has both a va_list declaration and a use of va_start. If the two are placed together, by moving the va_list declaration into the scope with the va_start, the problem does not occur. The general workaround is to ensure an expression appears before the first nested scope. Exactly how to do that will depend on the situation. A function with a nested scope that declares local variables and appears before any expressions in the function, and also declares top-level locals after that, may mishandle the local variables in a way that acts as though some share a location though they're supposed to be distinct. I.e., int test(int arg, ...) { { int a = 0; } int b; may mishandle a, b, arg, or any extra arguments. Known cases all involve the ellipsis (...) parameter, but it is not known if that is also a necessary prerequisite.
CODEGEN-4622 Builtin test __has_builtin incorrectly claims to support many __builtin functions Fixed ARM_18.1.0.LTS ARM_18.1.2.LTS Do not use __has_builtin until it is fixed. MCU release 18.1.x.LTS added the __has_builtin feature to detect whether or not a particular builtin function was supported. However, this feature test mistakenly returned true for a great number of builtins that the TI compiler does not support.
CODEGEN-4605 Incompatible redeclaration error with -o4 when using anonymous unions Fixed ARM_18.1.0.LTS ARM_18.1.2.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 ARM_18.1.0.LTS ARM_18.1.3.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-4581 Using the C interlister with C++14 features may generate error Fixed ARM_18.1.0.LTS ARM_18.1.2.LTS Do not use the -s source interlisting option When using the -s C source interlisting option, the compiler may emit a bogus assembly directive for functions which do not have a body in the source code (e.g. certain implicit constructors). The assembler will emit an error when encountering this directive.
CODEGEN-4576 hex --ascii option truncates address to 16 bits Fixed ARM_18.1.0.LTS ARM_18.1.2.LTS 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-4525 Unreachable code in linear assembly may lead to crash Fixed ARM_18.1.0.LTS ARM_18.1.3.LTS Remove the unreachable code before compiling, or compile with -o1, -o0, or -ooff, or use --symdebug:none which happens to avoid the problem. The compiler may crash if given a linear assembly file containing some code that has a label but is not reachable. It's theoretically possible to create the same problem with C/C++ code, but we haven't been able to do it and the risk is quite small.
CODEGEN-4498 When you link with --opt_level=4 and -mv7R5, linker complains about object file incompatibility Planned ARM_18.1.1.LTS ARM_18.1.6.LTS Decrease optimization to -O3
CODEGEN-4426 Compiler crashes when building TI-RTOS in SIMPLELINK-MSP432-SDK 1.60.00.12 version of the SDK Fixed ARM_18.1.0.LTS ARM_18.1.1.LTS The failure was found when building the gpiointerrupt_MSP_EXP432P401R_tirtos_ccs project from version 1.60.00.12 of the Simplelink MSP432 SDK. However, the failure occurs when building TI-RTOS kernel so most likely affects all examples. The failure has only been reproduced on OSX, but it could be encountered on any OS. The failure is a crash and will result in an error message like: INTERNAL ERROR: armacpia experienced a segmentation fault while processing function (unknown or file scope) file (unknown) line 0 This is caused by a defect in the TI EABI C/C++ Parser. >> Compilation failure TI Customer Support may be able to suggest a workaround to avoid this. Upgrading to the newest version of the compiler may fix this problem.
CODEGEN-4419 Compiler erroneously speculates indexed load from the stack Fixed ARM_18.1.0.LTS ARM_18.1.2.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 ARM_18.1.0.LTS ARM_18.1.2.LTS Remove unnecessary const from helper in s__algo.c
CODEGEN-4339 div() and ldiv() return incorrect result when built with -o4 option Fixed ARM_18.1.0.LTS ARM_18.1.0.LTS
CODEGEN-4280 Using ULP advisor with C++ templates may cause the compiler to crash Fixed ARM_18.1.0.LTS ARM_18.1.2.LTS The compiler may crash when using ULP advisor on C++ code that contains templates
CODEGEN-4251 ECC section names are randomly assigned Fixed ARM_18.1.0.LTS This happens in 16.9.X.LTS because the ECC initialization code iterates over an unsorted list. This list's order happens to be non-deterministic. The ECC code was refactored significantly before the 17.3 branch, and now uses a set, which is always ordered. Thus, the problem will not occur in 17.3.0.STS or any release thereafter. We do not plan to address this for the 16.9.X.LTS branch.
CODEGEN-4182 Should ignore option --pending_instantiations when compiling C files Fixed ARM_18.1.0.LTS ARM_18.1.2.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 ARM_18.1.0.LTS ARM_18.1.2.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 ARM_18.1.0.LTS ARM_18.1.2.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-3955 libc++ has incorrect implementation of pointer_safety Fixed ARM_18.1.0.LTS ARM_18.1.0.LTS The implementation of std::pointer_safety is a struct, rather than as an enum_class, as required by the C++ standard.
CODEGEN-3931 Compiler crashes while handling 0 length array in zero sized struct Fixed ARM_18.1.0.LTS ARM_18.1.2.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 ARM_18.1.0.LTS ARM_18.1.3.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-3880 Compiler generates invalid instruction with VFP registers Fixed ARM_18.1.0.LTS No practical workaround When using --float_support, it is sometimes possible for VFP registers to show up in regshift operands. If you do not get an error from the assembler, you are not suffering from this bug.
CODEGEN-3858 OFD gets DIE attribute offset wrong when using --dwarf_display=none,dinfo Fixed ARM_18.1.0.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 ARM_18.1.0.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 ARM_18.1.0.LTS ARM_18.1.2.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-3711 Uses of __strex intrinsics are deleted Fixed ARM_18.1.0.LTS The compiler supports synchronization primitive intrinsics, but always deletes calls to __strex, __strexb, __strexh, and __strexd.
CODEGEN-3619 pragma triggers false MISRA-C:2004 19.1/A warning Fixed ARM_18.1.0.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-3595 Stack usage under reports stack amount used because it fails to handle function aliases Fixed ARM_18.1.0.LTS ARM_18.1.2.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-2373 Internal linker error triggered by function alias Fixed ARM_18.1.0.LTS Linker sometimes generates "Assertion failed" message and aborts.
CODEGEN-2320 ARM compiler fails to truncate scaled offset to byte Fixed ARM_18.1.0.LTS Compile with --opt_level=off. This is not an optimization bug; however, the bug does not manifest at --opt_level=off. The compiler matches X[(unsigned char)(Y >> 16)] with an indexed addressing mode, but it can't because that doesn't truncate the array index to 8 bits.
CODEGEN-2257 Using --no_stm may discard regsave debugging information Fixed ARM_18.1.0.LTS ARM_18.1.0.LTS Don't use --no_stm unless you are sure it is necessary When using the --no_stm silicon workaround option for Cortex-R4, some debugging information may be lost, leading to the debugger having trouble unwinding functions, and thus being unable to show the call stack.
CODEGEN-1979 Statements before declarations with no white space (aggravated by macros) may cause incorrect parser error Fixed ARM_18.1.0.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.
SDSCM00051292 __rev should accept and return an unsigned int instead of a signed int. Fixed ARM_18.1.0.LTS
SDSCM00051067 Width-modified LDR/STREX instructions should be rejected on V6 Fixed ARM_18.1.0.LTS While LDREX and STREX are available on v6, all of the other EX instructions aren't available until v6k, which we do not support. For TI hardware, we begin to support these instructions in v7. The assembler should reject the instructions LDREXH, LDREXB, LDREXD, STREXH, STREXB, and STREXD for v6, including v6M0. We already treat CLREX correct and reject it for v6.
SDSCM00051066 Should reject MLS on pre-Thumb-2 devices Fixed ARM_18.1.0.LTS MLS is a Thumb2 instruction; it should be rejected on earlier architectures, including Cortex-M0
SDSCM00050131 Local struct with non-constant initializer treated as static scope variable Fixed ARM_18.1.0.LTS ARM_18.1.5.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.
SDSCM00047902 Predefined macro __TI_FPv4SPD16_SUPPORT__ should be __TI_FPV4SPD16_SUPPORT__ Fixed ARM_18.1.0.LTS
SDSCM00046352 Disassembler fails to emit certain instructions in UAL form Fixed ARM_18.1.0.LTS For certain instructions combining the S flag and a condition code, UAL requires the S to appear before the condition code, but the disassembler puts it afterward, in the pre-UAL style.
SDSCM00043877 Emit error message when objects too large for infrastructure (roughly 512MiB, or 256MiWords) are truncated Fixed ARM_18.1.0.LTS N/A Due to an internal limitation, the code generation tools cannot presently allocate objects larger than roughly 512MiB (roughly 256MiWords). Data objects larger than this are silently truncated to a much smaller size. When such objects are declared in the code, they are silently truncated and compilation continues without any diagnostics.
SDSCM00043334 Should reject illegal MOVS instruction which cannot set status Fixed ARM_18.1.0.LTS The assembler accepts instructions like "MOVS R0, R10" in thumb mode, but should not. There is no instruction which can perform this move while setting the status bits.
SDSCM00037227 Bad disassembly for VMRS APSR_nzcv, FPSCR Fixed ARM_18.1.0.LTS The ARM disassembler mistakenly disassembles "VMRS APSR_nzcv, FPSCR" as "VMRS PC, FPSCR"
SDSCM00037086 ARM assembler allows incorrect VFP registers for some instructions on D16 VFP architectures Fixed ARM_18.1.0.LTS For devices with VFP D16, the assembler should not allow instructions using registers D16-D31, but it does.

Generated on Fri May 24 14:36:09 2019