Closed Defects in Release

ID Summary State Reported In Release Target Release Workaround Release Notes
CODEGEN-5387 Loop with early exit may peel incorrectly when unrolling (as with -mf3 or above) Fixed ARM_16.9.0.LTS ARM_16.9.10.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-5236 Register allocation failure Fixed ARM_16.9.0.LTS ARM_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-5127 Linker fails with INTERNAL ERROR: no match for COMMA Fixed ARM_16.9.0.LTS ARM_16.9.10.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-5032 Loop over array, preceded by shuffle of the array using scalar temp repeatedly, may produce incorrect results Fixed ARM_16.9.0.LTS ARM_16.9.10.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-4912 Including stddef.h may disable MISRA diagnostics Fixed ARM_16.9.0.LTS ARM_16.9.9.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_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.7.LTS ARM_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-4668 Macro with temp label causes assembler to crash Fixed ARM_16.9.0.LTS ARM_16.9.9.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_16.9.0.LTS ARM_16.9.8.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_16.9.0.LTS ARM_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-4634 Use of stdarg.h va_start macro causes a write to the wrong local variable Fixed ARM_16.9.0.LTS ARM_16.9.9.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-4623 Compiler incorrectly optimizes away member functions which arise from explicit template instantiation Fixed ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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-4525 Unreachable code in linear assembly may lead to crash Fixed ARM_16.9.0.LTS ARM_16.9.9.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-4419 Compiler erroneously speculates indexed load from the stack Fixed ARM_16.9.0.LTS ARM_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 ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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-3880 Compiler generates invalid instruction with VFP registers Fixed ARM_16.9.0.LTS ARM_16.9.7.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-3876 Code incorrectly removed from functions calling "naked" attribute functions Fixed ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.4.LTS ARM_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 ARM_16.9.0.LTS ARM_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-3711 Uses of __strex intrinsics are deleted Fixed ARM_16.9.0.LTS ARM_16.9.6.LTS The compiler supports synchronization primitive intrinsics, but always deletes calls to __strex, __strexb, __strexh, and __strexd.
CODEGEN-3650 Linker crashes when printing module list to map file Fixed ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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-2373 Internal linker error triggered by function alias Fixed ARM_16.9.0.LTS ARM_16.9.6.LTS Linker sometimes generates "Assertion failed" message and aborts.
CODEGEN-2320 ARM compiler fails to truncate scaled offset to byte Fixed ARM_16.9.0.LTS ARM_16.9.6.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-2286 palign(8) of .init_array messes up __TI_INITARRAY_Limit address Fixed ARM_16.9.0.LTS ARM_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-2257 Using --no_stm may discard regsave debugging information Fixed ARM_16.9.6.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-2238 Compiler incorrectly emits MISRA 10.1 for function argument Fixed ARM_16.9.0.LTS ARM_16.9.6.LTS
CODEGEN-2214 Compiler optimizes away function which calls assert Fixed ARM_16.9.0.LTS ARM_16.9.4.LTS Make sure there is some other visible effect in the function -- a call, a use of a volatile variable, something like that. A function whose only visible effect is to call assert() may be optimised away at --opt_level=0 or higher.
CODEGEN-2209 Link error with gcc debug information Fixed ARM_16.9.0.LTS ARM_16.9.4.LTS None When linking against GCC code, a project failed to build due to a relocation error, generating the message "fatal error #10232". Specifically, the problem was caused by debug information left in the GCC object file for eliminated comdat sections. GCC puts debug information into a common section called .debug_info. Once the comdat section was eliminated, the debug symbol pointed to a deleted section, causing an error in the TI linker.
CODEGEN-2143 Anonymous struct in union causes type merging failure at -O4 Fixed ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_16.9.2.LTS
CODEGEN-2047 CMSIS Core v5 is not compliant with TI ARM Compiler Fixed ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_16.9.3.LTS
CODEGEN-2010 Decomp error involving packed class Fixed ARM_16.9.0.LTS ARM_16.9.2.LTS Fixed an issue that could result in a "Decomposition error" abort of the compiler.
CODEGEN-1979 Statements before declarations with no white space (aggravated by macros) may cause incorrect parser error Fixed ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_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-1640 MISRA 19.1 misreported: #include statements should only be preceded by other preprocessor directives Fixed ARM_16.9.0.LTS ARM_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 ARM_16.9.0.LTS ARM_16.9.4.LTS
CODEGEN-1634 MISRA 7.1 misreported: octal tokens in token paste Fixed ARM_16.9.0.LTS ARM_16.9.1.LTS No practical workaround
CODEGEN-1632 MISRA 15.2 misreported: switch clause unconditional break Fixed ARM_16.9.0.LTS ARM_16.9.1.LTS Put an explicit break at the end of the compound statement
CODEGEN-1555 Incorrect result for ullong expression passed to abs Fixed ARM_16.9.0.LTS ARM_16.9.1.LTS Use llabs instead of abs abs(x-y) may compute an incorrect result when x and y are unsigned long long variables.
CODEGEN-1517 #pragma FUNCTION_OPTIONS meaningless unless at least -o0 is used Fixed ARM_16.9.0.LTS
CODEGEN-1429 Software pipelined loop generates different results than loop not pipelined Fixed ARM_16.9.0.LTS ARM_16.9.0.LTS Avoid unsigned expressions in subscripts or in computing subscripts, or compile with -o1 or -o0.
SDSCM00052814 TMS570LC4357 ECC algorithm not supported Fixed ARM_16.9.0.LTS ARM_16.9.1.LTS There is a backdoor in the implementation that you can use to realize this new algorithm. Use this algorithm specification: ECC { algo_name : address_mask = 0xffffffff hamming_mask = /* address */ 0x53aaa750, 0xeb45d688, 0xa6d54da8, 0x9e353c68, 0x7e0cfc18, 0xfe03fc00, 0x01fffc00, 0xfe0003f8, /* upper */ 0x2E4B2E4B, 0x57155715, 0x99A699A6, 0xE338E338, 0xFCC0FCC0, 0x00FF00FF, 0xFF0000FF, 0xFF0000FF, /* lower */ 0xD1B4D1B4, 0x57155715, 0x99A699A6, 0xE338E338, 0xFCC0FCC0, 0x00FF00FF, 0xFF0000FF, 0x00FFFF00, parity_mask = 0x0c mirroring = F021 } If you value your sanity, do not ask where the constants come from. Some devices, such as TMS570LC4357 Hercules, have a FLASH bank in high memory, and ECC uses the high bits of the address in the ECC calculation. Therefore, we need to extend the participating address bits mask in the linker-generated ECC handling.
CODEGEN-1333 Structure assignment causes compiler to fail with INTERNAL ERROR: Decomposition error Fixed ARM_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-1312 RTS header errno.h no longer defines POSIX macros like EFAULT Fixed ARM_16.9.1.LTS
CODEGEN-1287 Compiler and documentation disagree on default for --enum_type Fixed ARM_16.9.0.LTS
SDSCM00040386 Remove -olength option from hex utility's help summary and Users Guides Fixed ARM_16.9.0.LTS ARM_16.9.0.LTS
SDSCM00052902 Assembler incorrectly issues error message: Address must be of a non-global defined in the current section Fixed ARM_16.9.0.LTS The suggested workaround is to go back to 15.12.3.LTS until the next ARM compiler release is available. Alternately, alter the code such that the target label is a non-global symbol defined in the same section as the branch. If the symbol must be global, add a second non-global label such as fake_label and change the branch to "B fake_label".
SDSCM00052734 Internal error in trampoline generation when user defines data symbol named "signal" Fixed ARM_16.9.0.LTS It is a user error to have two different objects in the system with the same name. Rename one of the objects.
SDSCM00051485 Incorrect reordering of nested op= with ++ Fixed ARM_16.9.0.LTS ARM_16.9.0.LTS Don't embed "X op= Y++" under another assignment operator. An expression like "a += b += c++" will produce the wrong answer. The problem is specific to sub-expressions of the form "X op= Y++" that occur under another assignment operator.
SDSCM00051067 Width-modified LDR/STREX instructions should be rejected on V6 Fixed ARM_16.9.0.LTS ARM_16.9.6.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_16.9.0.LTS ARM_16.9.6.LTS MLS is a Thumb2 instruction; it should be rejected on earlier architectures, including Cortex-M0
SDSCM00046352 Disassembler fails to emit certain instructions in UAL form Fixed ARM_16.9.0.LTS ARM_16.9.6.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_16.9.0.LTS ARM_16.9.7.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_16.9.0.LTS ARM_16.9.6.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_16.9.0.LTS ARM_16.9.6.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_16.9.0.LTS ARM_16.9.6.LTS For devices with VFP D16, the assembler should not allow instructions using registers D16-D31, but it does.

Generated on Thu Dec 13 10:18:17 2018