| 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 |
|
|
