Closed Defects in Release

ID Summary State Reported In Release Target Release Workaround Release Notes
CODEGEN-5943 Compiler may lose volatile qualifier in A->B->C when B and C are both volatile Fixed PRU_2.3.0 PRU_2.3.2 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 PRU_2.3.0 PRU_2.3.2
CODEGEN-5791 C++ enum class with explicit type has some problems Fixed PRU_2.3.0 PRU_2.3.2 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-5674 Under -o4, compiler may assume a global variable is constant, if it's only set in files containing inline asm() Fixed PRU_2.3.0 PRU_2.3.2 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 PRU_2.3.0 PRU_2.3.2 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 PRU_2.3.0 PRU_2.3.2 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-5527 Local structure initialization is incorrectly optimized away Fixed PRU_2.3.0 PRU_2.3.2 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 PRU_2.3.0 PRU_2.3.2
CODEGEN-5236 Register allocation failure Fixed PRU_2.3.0 PRU_2.3.2 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-5119 Using #pragma RETAIN does not keep a static file level variable Fixed PRU_2.3.0 PRU_2.3.2 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 PRU_2.3.0 PRU_2.3.2
CODEGEN-4926 Packed structures generate unnecessary code on PRU Fixed PRU_2.3.0 Don't use the packed attribute for PRU. The use of the packed attribute on PRU should not result in any different code since PRU has native unaligned access. However, unnecessary code is being generated.
CODEGEN-4885 See MISRA diagnostics when compiling stdio.h Fixed PRU_2.3.0 PRU_2.3.2 none A program that includes <stdio.h> and checks for MISRA warnings may see some from stdio.h itself, which should not happen.
CODEGEN-4832 Compiler manual mistakenly states #pragma pack is supported Fixed PRU_2.3.0 PRU_2.3.0
CODEGEN-4791 Structure field reference directly from function call causes INTERNAL ERROR Fixed PRU_2.3.0 Compile with any value of --opt_level except "off". Or, given the expression f().x, change it to "t=f(); t.x"; in other word, capture the struct returned from the function call in a variable, and make the field reference from that variable instead of directly from the function call. Compiling an expression like f().x -- a function call immediately used to make a structure field reference -- can cause the compiler to abort with INTERNAL ERROR. Any use of the optimiser, or a simple code rearrangement, avoids the problem.
CODEGEN-4700 Incorrect diagnostic when using macro that comes from macro library Fixed PRU_2.3.0 PRU_2.3.2 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 PRU_2.3.0 PRU_2.3.0 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-4643 Documentation incorrectly lists __builtin_sqrt as being supported Fixed PRU_2.3.0
CODEGEN-4638 When shift counts are higher than 32, compiler sometimes optimizes to an incorrect shift count Fixed PRU_2.3.0 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 PRU_2.3.0 PRU_2.3.2 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-4605 Incompatible redeclaration error with -o4 when using anonymous unions Fixed PRU_2.3.0 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 PRU_2.3.0 PRU_2.3.1 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-4576 hex --ascii option truncates address to 16 bits Fixed PRU_2.3.0 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-4419 Compiler erroneously speculates indexed load from the stack Fixed PRU_2.3.0 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 PRU_2.3.0 Remove unnecessary const from helper in s__algo.c
CODEGEN-4182 Should ignore option --pending_instantiations when compiling C files Fixed PRU_2.3.0 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-4180 PRU compiler fails to account for zero-sized struct passed in register as function argument Fixed PRU_2.3.0 If an empty struct is passed as a function argument, the caller function passes 0 in a register but the called function ignores the argument. This results in the subsequent argument being allocated to a different register than the one the caller used. Now, both caller and callee functions ignore zero-sized struct arguments.
CODEGEN-4178 Update PRU documentation to include that 24-bit structs are also passed in registers Fixed PRU_2.3.0
CODEGEN-4113 Assembler computes wrong result for expression 0x232800 % 0x10000 Fixed PRU_2.3.0 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 PRU_2.3.0 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 PRU_2.3.0 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 PRU_2.3.0 No practical workaround. Some optimizations in the compiler would change instructions but fail to retain debugging directives attached to those instructions. This could impact the accuracy of the DWARF debugging information in various ways.
CODEGEN-3918 Writing multiple input sections in one line unexpectedly changes how input sections are combined into output sections Fixed PRU_2.3.0 Stick with separate lines, if there are subsection cases like this one that should be comprehended. In a linker command file, using a line like "hello.obj (.const, .far)" may link differently than two lines with one section each. The problem is that the single line is interpreted as the OR of the two sections, and the linker does not understand that the OR also encompasses any of their subsections. Two separate lines are analysed separately and completely.
CODEGEN-3794 False warning for MISRA 10.1/10.2 when commutative binary operands swapped Fixed PRU_2.3.0 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-3595 Stack usage under reports stack amount used because it fails to handle function aliases Fixed PRU_2.3.0 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.
SDSCM00052006 ltoa definition conflicts with quasi-standard ltoa Fixed PRU_2.3.0 PRU_2.3.2 Don't use ltoa; instead use sprintf. For a long time, the TI RTS has defined a function named ltoa used in printf. However, quasi-standard function ltoa with a different prototype has been floating around the net for even longer. The presence of TI's definition causes problems for applications which attempt to use ltoa. It's difficult for the user to override the definition in their program to use the quasi-standard version, because TI has a prototype for the bogus version in stdlib.h This defect has been resolved by renaming TI's ltoa to something in the implementation namespace. Additionally, we've added a definition of ltoa conforming to the quasi-standard version.
SDSCM00050131 Local struct with non-constant initializer treated as static scope variable Fixed PRU_2.3.0 PRU_2.3.2 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.
SDSCM00043877 Emit error message when objects too large for infrastructure (roughly 512MiB, or 256MiWords) are truncated Fixed PRU_2.3.0 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.
SDSCM00014430 calloc doesn't check arguments to make sure the requested size is reasonable Fixed PRU_2.3.0 PRU_2.3.0

Generated on Wed May 15 13:23:38 2019