ID Summary State Reported In Release Target Release Workaround Release Notes
CODEGEN-5580 C28 tmu1 __relaxed_powf bug Fixed C2000_18.9.0.STS C2000_18.12.0.LTS Either use --fp_mode=strict or update include/math.h with below: __inline float __relaxed_powf(float x, float y) { float log2ofx = __log2(x); float log2ofxtimesy = log2ofx * y; float exp2foflog2ofxtimesy = exp2f(log2ofxtimesy); return log2ofxtimesy > 0 ? exp2foflog2ofxtimesy : 1.0f / exp2foflog2ofxtimesy; } Using --tmu_support=tmu1 --fp_mode=relaxed, below math.h routine did not properly handle a negative result for log2(x): __inline float __relaxed_powf(float x, float y) { float log2ofx = __log2(x); float log2ofxtimesy = log2ofx * y; return exp2f(log2ofxtimesy); } Updated routine that handles negative log2(x): __inline float __relaxed_powf(float x, float y) { float log2ofx = __log2(x); float log2ofxtimesy = log2ofx * y; float exp2foflog2ofxtimesy = exp2f(log2ofxtimesy); return log2ofxtimesy > 0 ? exp2foflog2ofxtimesy : 1.0f / exp2foflog2ofxtimesy; }
CODEGEN-5551 C2000 ALT Guide lists incorrect processor symbolic constants Planned C2000_18.12.0.LTS C2000_18.12.0.LTS The following processor constants listed in table 4.7.6 "Predefined Symbolic Constants" in the C2000 Assembly Language Tools user's guide don't exist: TMS320C2800_CLA TMS320C2800_TMU Each of the available CLA, TMU and VCU processor constants is set to 1 if that value or greater of the device option is used.
CODEGEN-5460 Matching failure for intrinsic __euclidean_div_i32byu32 Fixed C2000_18.9.0.STS C2000_18.12.0.LTS Use intrinsics __rpt_subcul and __subcul When using the intrinsic __euclidean_div_i32byu32, the compiler will fail with an error similar to "no match for COMMA"
CODEGEN-5387 Loop with early exit may peel incorrectly when unrolling (as with -mf3 or above) Fixed C2000_18.1.0.LTS, C2000_18.9.0.STS C2000_18.12.0.LTS, C2000_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-5317 Ternary (?:) expression with 0/1 result uses type of predicate, not result, when optimised Fixed C2000_18.1.0.LTS, C2000_18.9.0.STS C2000_18.12.0.LTS, C2000_18.1.4.LTS Compile with -Ooff. An expression like "(p ? 1 : 0)" can be converted by the compiler into "(p != 0)". If the types of 1 and 0 are wider than int, and the expression is shifted left, as in "(p ? 1UL : 0UL) << 16", then the value shifted will be int instead of the wider type, and the overall value will be incorrect.
CODEGEN-5187 Compiler mishandles signed right-shifts by 16 on targets with 16-bit ints Fixed C2000_18.1.0.LTS, C2000_18.12.0.LTS C2000_18.12.0.LTS, C2000_18.1.5.LTS* None known. For MSP430 and C2000, a right-shift of a signed long (ie, 32-bit) expression by 16 -- X>>16 -- will be compiled as an unsigned right-shift, which can lead to incorrect sign-extensions in the result.
CODEGEN-5174 Error in workaround for CODEGEN-3721 Fixed C2000_18.1.3.LTS C2000_18.9.0.STS, C2000_18.1.5.LTS* Rewrite the code to avoid "<=" or ">=" integer comparisons. This may not always be possible, because the optimizer may rearrange other integer comparisons to create "<=" or ">=" comparisons. Integer <= and >= comparisons may falsely return "true" for some inputs. This will only happen for inputs that have more than 24 significant binary digits but vary in the lowest bits. The more significant binary digits the values have, the more bits may vary in the lowest end of the values and still falsely compare equal.
CODEGEN-5032 Loop over array, preceded by shuffle of the array using scalar temp repeatedly, may produce incorrect results Fixed C2000_18.1.0.LTS, C2000_18.9.0.STS C2000_18.12.0.LTS, C2000_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-4885 See MISRA diagnostics when compiling stdio.h Fixed C2000_18.1.0.LTS, C2000_18.9.0.STS, C2000_18.12.0.LTS C2000_18.12.0.LTS, C2000_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-4721 Linker crashes with INTERNAL ERROR: lnk2000 experienced a segmentation fault Fixed C2000_18.1.0.LTS, C2000_18.9.0.STS C2000_18.9.0.STS, C2000_18.1.3.LTS None. In the right (or wrong) circumstances, the linker may crash or print an error message and exit. The immediate reason is memory corruption caused by an errant data structure, which means that it's very hard to specify exactly how to reproduce or avoid it. There is no known workaround.
CODEGEN-4668 Macro with temp label causes assembler to crash Fixed C2000_18.1.0.LTS, C2000_18.12.0.LTS C2000_18.9.0.STS, C2000_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-4600 Warning when using pragma RETAIN with attribute((noinit)) Fixed C2000_18.1.0.LTS, C2000_18.9.0.STS C2000_18.9.0.STS, C2000_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-4496 CLA compiler passes function arguments incorrectly and issues linker error Fixed C2000_18.1.0.LTS, C2000_18.9.0.STS C2000_18.9.0.STS, C2000_18.1.2.LTS None The CLA linker issues an undefined symbol error for a CLA math library function's scratchpad (__cla_CLAsincos_sp). The fundamental bug is that the CLA code generator is erroneously passing a function argument on the function's scratchpad even though it should be passed in a register, and then zeroing out the register. Additionally, the function is a CLA math library function which has defined an incorrect scratchpad name, so once the function's scratchpad is referenced, the linker issues an undefined symbol error because there is no definition for the legitimate function scratchpad name. However, the function's scratchpad should not be referenced to begin with. The bug was introduced in C2000 CGT v17.3.0.STS.
CODEGEN-3595 Stack usage under reports stack amount used because it fails to handle function aliases Fixed C2000_18.1.0.LTS C2000_18.9.0.STS, C2000_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.
SDSCM00014430 calloc doesn't check arguments to make sure the requested size is reasonable Fixed C2000_18.1.0.LTS C2000_18.9.0.STS

Generated on Sat Dec 15 11:51:56 2018