C2000 C/C++ CODE GENERATION TOOLS
6.4.3 February 2015
Defect History

-------------------------------------------------------------------------------
Table of Contents
-------------------------------------------------------------------------------
1. Defects fixed in C2000 Code Generation Tools release 6.4.3
2. Defects fixed in C2000 Code Generation Tools release 6.4.2
3. Defects fixed in C2000 Code Generation Tools release 6.4.1
4. Defects fixed in C2000 Code Generation Tools release 6.4.0
5. Defects fixed in C2000 Code Generation Tools release 6.4.0B1
6. Current Known Issues


===============================================================================
1. Defects fixed in C2000 Code Generation Tools release 6.4.3
===============================================================================

The following 9 defects were fixed in C2000 Code Generation Tools release
6.4.3, released February 2015.

-------------------------------------------------------------------------------
FIXED SDSCM00044254
-------------------------------------------------------------------------------

Summary            : c2000 hextool maximum block size limitation

Fixed in           : 6.4.3
Severity           : S2 - Major
Affected Component : Hex Converter (hex)

Release Notes:
  On some devices, Hextool may cause the bootloader to hang due to the
  creation of a maximum length boot block (0xFFFF). The maximum length
  will be lowered to 0xFFFE.
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.10, 6.2.9 - 6.2.10, 6.4.0B1 - 6.4.2

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00050959
-------------------------------------------------------------------------------

Summary            : SIGSSEGV when using % in an option argument

Fixed in           : 6.4.3
Severity           : S2 - Major
Affected Component : Shell

Release Notes:
  In some cases, the compiler passes user-created identifiers directly to a
  function which behaves like printf without using a format string. If the
  user's identifier contains any printf-special characters, the compiler may
  crash.
  
  Defect occurs in C2000 Compiler versions: 6.4.0B1 - 6.4.2

Workaround:
  Don't use any printf-special characters like % in a compiler argument

-------------------------------------------------------------------------------
FIXED SDSCM00051388
-------------------------------------------------------------------------------

Summary            : Compiler emits illegal instruction for SP save

Fixed in           : 6.4.3
Severity           : S2 - Major
Affected Component : Code Generator

Release Notes:
  On C2000, an illegal store of the stack pointer to memory may be
  generated. This bug has only been seen at optimization level 2 and above
  but could occur at a lower level. If affected assembly is generated, the
  assembler will error with "Illegal operand combination."
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.10, 6.2.4 - 6.2.10, 6.4.0B1 - 6.4.2

Workaround:
  Changing the optimization level for an affected file will most likely
  avoid the error.

-------------------------------------------------------------------------------
FIXED SDSCM00051389
-------------------------------------------------------------------------------

Summary            : Compiler emits RPTB that is too large

Fixed in           : 6.4.3
Severity           : S2 - Major
Affected Component : Code Generator

Release Notes:
  The compiler treated the instruction ADDUL P, loc32 as if it were 16
  bits. However, it is actually 32 bits. If the compiler used this
  instruction in an RPTB, it would underestimate the size of the RPTB,
  and could potentially create an RPTB that was too large to be legal.
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.10, 6.4.0B1 - 6.4.2

Workaround:
  No practical workaround

-------------------------------------------------------------------------------
FIXED SDSCM00051394
-------------------------------------------------------------------------------

Summary            : Loop containing floating-point min or max reduction may
                     cause compiler crash

Fixed in           : 6.4.3
Severity           : S2 - Major
Affected Component : Optimizer

Release Notes:
  A loop containing a min or max reduction -- ie
  
    for ...
    a = (a > b) ? a : b;
  
  when all the expressions are floating-point and the code is compiled with
  --float_support=fpu32 or fpu64, may cause the compiler to crash.
  
  Defect occurs in C2000 Compiler versions: 6.4.0B1 - 6.4.2

Workaround:
  Compile with -o0 or -o1, or use -mf0, -mf1, or -mf2, or add "#pragma
  UNROLL(1)" to the offending loop.

-------------------------------------------------------------------------------
FIXED SDSCM00051472
-------------------------------------------------------------------------------

Summary            : Conditionals that use shift operator may be optimized
                     out

Fixed in           : 6.4.3
Severity           : S2 - Major
Affected Component : Optimizer

Release Notes:
  Shift operations in conditional statements may be optimized out, treating
  the result as 0. This will result in the entire conditional block being
  removed. NOTE: Intrinsics that perform shifts may be affected. In the
  observed test case, a shift was not explicitly used -- the C6x intrinsic
  _extu, which performs two shifts, was affected.
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.11, 6.4.0B1 - 6.4.2

Workaround:
  This behavior may be avoided by lowering the optimization level to -o1 or
  -o0. Moving the conditional check result to a variable so that the shift
  is not in the conditional may in some cases also avoid this behavior.

-------------------------------------------------------------------------------
FIXED SDSCM00051506
-------------------------------------------------------------------------------

Summary            : x -= y * z replaced with __parallel_mpy_add_f32

Fixed in           : 6.4.3
Severity           : S2 - Major
Affected Component : C/C++ Compiler (cl)
Duplicate Defects  : SDSCM00051514

Release Notes:
  Floating point operations of the form x -= y * z may be computed as x +=
  y * z on C2000. The issue is identifiable by the use of the MACF32
  (floating point multiply accumulate) instruction in affected loops.
  
  Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.11, 6.4.2

Workaround:
  Lower the optimization level to -o0 or -o1.
  Alternatively, changing the statement "x -= y * z" to "volatile float t =
  y * z; x -= t" should also avoid this behavior.

-------------------------------------------------------------------------------
FIXED SDSCM00051517
-------------------------------------------------------------------------------

Summary            : Stack is corrupted when --opt_for_space is used

Fixed in           : 6.4.3
Severity           : S2 - Major
Affected Component : Code Generator

Release Notes:
  When optimize for size is used on C2000 (-ms, --opt_for_space, -mf0), the
  prolog and/or epilog for a function may be replaced with library routines
  such as _prolog_c28x_2. If a prolog from the library is used, but an
  epilog from the library is not, this may result in not properly restoring
  all saved registers from the stack.
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.11, 6.4.2

Workaround:
  Disable/lower optimization for size.
  Note: Normal optimization levels (-o[0-4]) do not affect this bug.
        Lowering or removing the use of -ms (--opt_for_space) and -mf to favor
        performance over size will alleviate this behavior.

-------------------------------------------------------------------------------
FIXED SDSCM00051562
-------------------------------------------------------------------------------

Summary            : The C2000 compiler produces the following instruction:
                     MOV *+FP[AR0],SP

Fixed in           : 6.4.3
Severity           : S2 - Major
Affected Component : Code Generator

Release Notes:
  The compiler will no longer generate this sequence.
  
  Defect occurs in C2000 Compiler versions: 6.4.0 - 6.4.2

Workaround:
  There is no obvious workaround, but most like reducing the optimization
  level or adjusting the size/speed trade off (--opt_for_speed) will perturb the
  code enough to avoid the issue.


===============================================================================
2. Defects fixed in C2000 Code Generation Tools release 6.4.2
===============================================================================

The following 4 defects were fixed in C2000 Code Generation Tools release
6.4.2, released January 2015.

-------------------------------------------------------------------------------
FIXED SDSCM00050992
-------------------------------------------------------------------------------

Summary            : The optimizer should not make a symbol an alias if it
                     has either the location or code_section pragmas applied.

Fixed in           : 6.4.2
Severity           : S2 - Major
Affected Component : Compiler Consultant (ci)

Release Notes:
  For a reason external to the expression of the program, the user relies
  on function X being at a particular address A. The only method the user
  has to do this is to put the function in its own special subsection and
  place it at A in the linker command file.

Workaround:
  Available workarounds are to:
  
  1. Reduce the optimization level to -o2.
  2. If using a COFF abi, you can move the functions into separate files.
  3. Add an __asm("NOP") to the function which will prevent an alias from
     being created.

-------------------------------------------------------------------------------
FIXED SDSCM00051144
-------------------------------------------------------------------------------

Summary            : CLA compiler issues warning about size_t when compiling
                     stddef.h

Fixed in           : 6.4.2
Severity           : S3 - Minor
Affected Component : C/C++ Compiler (cl)

Release Notes:
  When compiling for CLA, if stddef.h is included, the parser will warn:
  declaration of "size_t" does not match the expected type "unsigned int".
  Both types are 32 bits wide and compatible, so the warning may be safely
  ignored.
  
  Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.10, 6.2.9 - 6.2.10,
  6.4.0B1 - 6.4.1

Workaround:
  To silence the warning, either
  1) Disable the warning on the command line: cl2000 --cla_support -pds=921
  2) Disable the warning in source before the inclusion: #pragma
     diag_suppress 921

-------------------------------------------------------------------------------
FIXED SDSCM00051261
-------------------------------------------------------------------------------

Summary            : The exception handling (_eh) version of runtime library
                     is not automatically built when --exceptions option is
                     enabled

Fixed in           : 6.4.2
Severity           : S2 - Major
Affected Component : Runtime Support Libraries (RTS)

Release Notes:
  The exception handling (_eh) version of runtime library is not
  automatically built for projects that have --exceptions option enabled.
  This results in "undefined symbol" linker errors due to the incorrect rts
  library being linked in. This is caused by a missing build attribute in
  assembly files. This may be confirmed by examining the assembly for
  "Tag_Exceptions".
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.10, 6.4.0B1 - 6.4.1

Workaround:
  You can build the library manually. In a command terminal, browse to the lib
  dir of the code gen folder (ex. C:\ti\ccsv6\tools\compiler\c2000_6.2.7\lib)
  and run the following command:
  
  > set PATH=%PATH%;C:\ti\ccsv6\tools\compiler\c2000_6.2.7\bin
  > mklib --pattern=rts2800_eh.lib --index=libc.a --
  > install_to=C:/ti/ccsv6/tools/compiler/c2000_6.2.7/lib
  
  Update the paths to the CGT folder to match your install.
  
  Change the library name that is passed to the --patter option to build
  the other libraries for floating point (rts2800_fpu32_eh.lib) or large memory
  model (rts2800_ml_eh.lib).

-------------------------------------------------------------------------------
FIXED SDSCM00051267
-------------------------------------------------------------------------------

Summary            : Corrupted .cinit records for large data structures

Fixed in           : 6.4.2
Severity           : S2 - Major
Affected Component : Code Generator

Release Notes:
  A large statically initialized data structure may corrupt the
  initialization table. This may occur when: 1. The size of the structure
  is greater than the largest possible initialization record on the target.
  2. The COFF ABI is being used.
     This will result in the creation of a zero length initialization record
     immediately following the record for the large structure which will end
     the initialization process.
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.10, 6.4.0 - 6.4.1

Workaround:
  Data structures will need to be manually initialized.


===============================================================================
3. Defects fixed in C2000 Code Generation Tools release 6.4.1
===============================================================================

The following 4 defects were fixed in C2000 Code Generation Tools release
6.4.1, released December 2014.

-------------------------------------------------------------------------------
FIXED SDSCM00051126
-------------------------------------------------------------------------------

Summary            : Compiler mistakenly duplicates side-effect in function
                     call argument

Fixed in           : 6.4.1
Severity           : S2 - Major
Affected Component : Code Generator

Release Notes:
  If there is a side effect in a function call with an expression with the
  result of a 32-bit multiply feeding into a 32-bit add, the compiler could
  mistakenly duplicate the side effect, which could create incorrect behavior.
  The optimizer can create this scenario from user code that doesn't appear to
  have a side effect, such as an array index inside a loop.
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.10, 6.2.0 - 6.2.10, 6.4.0B1 - 6.4.0

Workaround:
  Put the value of the function call argument in a volatile local register
  before passing it to the function.

-------------------------------------------------------------------------------
FIXED SDSCM00051212
-------------------------------------------------------------------------------

Summary            : MSP 4.4.0 changes to _lock.h declaration of _nop(void)
                     instead of _nop() breaking driverlib

Fixed in           : 6.4.1
Severity           : S2 - Major
Affected Component : Runtime Intrinsics

Release Notes:
  MSP 4.4.0 RTS file _lock.h changed prototype for _nop() to _nop(void) which
  errors in parser for driverlib projects.

Workaround:
  Update _lock.h in the rts source folder, rename the library you are using, and
  it will automatically be rebuilt during next compile.
  
  To find compiler install location, click on project properties and click on:
  Resource->Linked Resources
  The "Path Variable" will have an entry for:
  CG_TOOL_ROOT c:\install_location\ccsv6\tools\compiler\msp430_4.3.4
  Within above folder look for:
  .\lib\src\_lock.h
  .\include\_lock.h
  
  Edit both of above files and change below line 47:
  _CODE_ACCESS void _nop(void);
  to remove void argument and instead be:
  _CODE_ACCESS void _nop();
  
  Rename the library you are using with suffix .old:
  .\lib\rtsx_lc_sd_eabi.lib
  change to a temp name
  .\lib\rtsx_lc_sd_eabi.lib.old
  
  Rebuild your project and the rts should automatically rebuild.

-------------------------------------------------------------------------------
FIXED SDSCM00051235
-------------------------------------------------------------------------------

Summary            : C2000 CGT v6.4 CLA linker errors

Fixed in           : 6.4.1
Severity           : S1 - Critical / PS
Affected Component : Linker

Release Notes:
  When compiling for CLA with the new C2000 CGT v6.4 compiler, the linker will
  generate errors if old linker command files are used. A patch will be released
  within the next couple of weeks to avoid this problem.

Workaround:
  Make the following changes to the linker command file:
  1) Remove the following:
     --undef_sym=__cla_scratchpad_end
     --undef_sym=__cla_scratchpad_start
  2) Add the following:
     .scratchpad : > CLARAM1, PAGE = 1

-------------------------------------------------------------------------------
FIXED SDSCM00051241
-------------------------------------------------------------------------------

Summary            : Output section splitting creates a zero-length section

Fixed in           : 6.4.1
Severity           : S2 - Major
Affected Component : ELF Linker

Release Notes:
  In certain rare cases, the linker might split an output section into
  several output sections such that one of them had zero length. The
  linker really ought not to create split zero-length sections, as it
  doesn't improve the linkability of the program. This can only happen
  if one of the input sections is of zero length.
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.10, 6.4.0B1 - 6.4.0

Workaround:
  1) Do not split the section in question. 2) Change the zero-length
     section so that it has at least one more byte.


===============================================================================
4. Defects fixed in C2000 Code Generation Tools release 6.4.0
===============================================================================

The following 2 defects were fixed in C2000 Code Generation Tools release
6.4.0, released November 2014.

-------------------------------------------------------------------------------
FIXED SDSCM00051097
-------------------------------------------------------------------------------

Summary            : Output section splitting creates a zero-length section

Fixed in           : 6.4.0
Severity           : S2 - Major
Affected Component : ELF Linker

Release Notes:
  In certain rare cases, the linker might split an output section into
  several output sections such that one of them had zero length. The
  linker really ought not to create split zero-length sections, as it
  doesn't improve the linkability of the program. This can only happen
  if one of the input sections is of zero length.
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.9, 6.4.0B1

Workaround:
  1) Do not split the section in question. 2) Change the zero-length
     section so that it has at least one more byte.

-------------------------------------------------------------------------------
FIXED SDSCM00051128
-------------------------------------------------------------------------------

Summary            : Alias missed on address of local passed as function
                     argument

Fixed in           : 6.4.0
Severity           : S2 - Major
Affected Component : Optimizer
Duplicate Defects  : SDSCM00047553

Release Notes:
  In certain cases, the compiler may produce incorrect code when a local
  variable whose address is passed to a function is then modified by the
  function, such as in the following example (where y is the affected local
  written by modf()):
  
  double f(double x)
  {
      double y = 0.;
      if(modf(x, &y) < 0.)
          return y - 1;
      else
          return y;
  }

Workaround:
  Use the -ma (--aliased_variables) option.


===============================================================================
5. Defects fixed in C2000 Code Generation Tools release 6.4.0B1
===============================================================================

The following 11 defects were fixed in C2000 Code Generation Tools release
6.4.0B1, released October 2014.

-------------------------------------------------------------------------------
FIXED SDSCM00049638
-------------------------------------------------------------------------------

Summary            : C code that reuses the same pointer a lot sees code size
                     that is almost 3X bigger than before

Fixed in           : 6.4.0B1
Severity           : S2 - Major
Classification     : Performance
Affected Component : C/C++ Compiler (cl)

Release Notes:
  The attached test case has lots of lines that look like ...
  
  ptr->array1[index] = ...
  ptr->array2[index] = ...
  ptr->array3[index] = ...
  
  The ptr never changes, but many other things do. I'm not sure this is central
  to the problem, but it certainly seems that way.
  
  The code generated by version 6.2.5 is nearly 3X larger than code
  generated with version 6.1.5.
  
  Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.9

Workaround:
  Make these changes to the build options.
  
  - Change --opt_level=2 to --opt_level=1
  - Add the option --opt_for_speed=0
  
  These changes avoid most of the code size increase, but not all of it.
  
  To see how you could apply these build option changes to only one file in
  a CCS project, please see http://processors.wiki.ti.com/index.php/Projects_an-
  d_Build_Handbook_for_CCS#File_specific_options

-------------------------------------------------------------------------------
FIXED SDSCM00049909
-------------------------------------------------------------------------------

Summary            : CLA compiler generates an internal error when indexing
                     into an array without optimization enabled

Fixed in           : 6.4.0B1
Severity           : S2 - Major
Affected Component : Code Generator

Release Notes:
  This bug is much more likely to occur if optimization is turned off. In
  many cases, setting the optimization level to 0 will resolve the issue.
  
  Defect occurs in C2000 Compiler versions: 6.1.7 - 6.1.8, 6.2.6

Workaround:
  Try turning optimization on.

-------------------------------------------------------------------------------
FIXED SDSCM00049997
-------------------------------------------------------------------------------

Summary            : Loop with volatile loop control expression removed

Fixed in           : 6.4.0B1
Severity           : S2 - Major
Affected Component : C/C++ Compiler (cl)

Release Notes:
  In some cases, the optimizer can remove apparently-empty loops that have
  a loop test which compares the loop control variable with a volatile
  value. This is not legal; the volatile value could change, so the loop
  must be left in the code.
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.7, 6.2.0B1 - 6.2.6, 6.3.0B1

Workaround:
  Declare the loop counter variable as volatile

-------------------------------------------------------------------------------
FIXED SDSCM00050023
-------------------------------------------------------------------------------

Summary            : SIGSEGV when using pragma on a template function

Fixed in           : 6.4.0B1
Severity           : S2 - Major
Affected Component : Parser

Release Notes:
  The compiler may emit an internal error (SIGSEGV) when the user attempts
  to apply a pragma to a template class function.
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.7, 6.2.0B1 - 6.2.6, 6.3.0B1

Workaround:
  Do not apply any pragma to a template function. Move the function
  outside the template class.

-------------------------------------------------------------------------------
FIXED SDSCM00050202
-------------------------------------------------------------------------------

Summary            : MISRA-C rule 19.11 false positive

Fixed in           : 6.4.0B1
Severity           : S3 - Minor
Affected Component : Parser

Release Notes:
  A violation of MISRA-C rule 19.11 may be falsely detected when a use of an
  undefined macro is guarded by a check to make sure that the macro is defined
  before use:
  
  #undef X
  #if defined(X) && X
  ...
  #endif

Workaround:
  Disable MISRA-C rule checking for 19.11 around the affected lines:
  
  #pragma CHECK_MISRA("-19.11")
  ...
  #pragma RESET_MISRA("19.11")

-------------------------------------------------------------------------------
FIXED SDSCM00050227
-------------------------------------------------------------------------------

Summary            : Illegal use of control register when setting all bits in
                     IFR

Fixed in           : 6.4.0B1
Severity           : S2 - Major
Affected Component : C/C++ Compiler (cl)

Release Notes:
  Sometimes the compiler will turn IFR |= 0xffff into IFR = 0xffff and
  then declares that this is an illegal use of IFR. The compiler should
  match IFR = 0xffff with an OR, as it matches IFR = 0 with IFR &= 0.
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.8, 6.2.0B1 - 6.2.6, 6.3.0B1

Workaround:
  Split the write to IFR into two parts that together contain all of the bits:
  IFR |= 0xff00;
  IFR |= 0x00ff;

-------------------------------------------------------------------------------
FIXED SDSCM00050243
-------------------------------------------------------------------------------

Summary            : Scary but harmless warning:  FAILURE in
                     mark_use_of_function_local_static()

Fixed in           : 6.4.0B1
Severity           : S2 - Major
Affected Component : Optimizer

Release Notes:
  Compiling for C++ and using -pm or -o4 may produce a warning like
  
  FAILURE in mark_use_of_function_local_static()
  fname1: __sti
  fname2: __sti_
  symbol: _$P$T62$2$1
  
  This warning, despite its dramatic wording, is harmless. The compiler
  will build the program just as it should, and the warning does not
  indicate any change in behavior. It's a debugging message that should
  not have been visible outside the development team.
  
  Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6,
  6.1.0B1 - 6.1.8, 6.2.0B1 - 6.2.7

Workaround:
  Avoid -pm or -o4. But the warning doesn't indicate any change of the
  compiler's behavior, so you might as well ignore it.

-------------------------------------------------------------------------------
FIXED SDSCM00050302
-------------------------------------------------------------------------------

Summary            : Assembler emits spurious ECN error

Fixed in           : 6.4.0B1
Severity           : S2 - Major
Affected Component : Assembler

Release Notes:
  The compiler can emit code that triggers a spurious error for FPU
  MMWRITE ECN2 (see SDSCM0045587). In this case, the assembly code has
  a MOV32, followed by an unconditional branch to another location,
  followed by a F32TOUI32. The assembler incorrectly emits the ECN
  error because it does not realize that control flow cannot reach the
  F32TOUI32 from the MOV32.
  
  Defect occurs in C2000 Compiler versions: 6.0.5 - 6.0.6, 6.1.2 - 6.1.8,
  6.2.0B1 - 6.2.7

Workaround:
  Adjust the optimization level, or place part of the expression in a
  volatile variable.

-------------------------------------------------------------------------------
FIXED SDSCM00050763
-------------------------------------------------------------------------------

Summary            : Only the C6000 compiler accepts the GCC builtin function
                     __builtin_constant_p

Fixed in           : 6.4.0B1
Severity           : S2 - Major
Affected Component : C/C++ Compiler (cl)

Release Notes:
  Error emitted that GNU __builtin_constant_p function not supported.

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00050967
-------------------------------------------------------------------------------

Summary            : Compiler generates incorrect code for a sequence that
                     swaps two values

Fixed in           : 6.4.0B1
Severity           : S2 - Major
Affected Component : C/C++ Compiler (cl)

Release Notes:
  Attempting to find min/max sequences to be replaced with intrinsics

Workaround:
  Either:
  1) Insert an assembly statement between the first two assignments of the swap,
     such as asm(" NOP");
  2) Don't run the optimizer for the affected file

-------------------------------------------------------------------------------
FIXED SDSCM00051050
-------------------------------------------------------------------------------

Summary            : Optimization produces incorrect floating point result

Fixed in           : 6.4.0B1
Severity           : S2 - Major
Affected Component : C/C++ Compiler (cl)

Release Notes:
  When compiling code involving floating-point multiplication and
  addition with hardware floating-support enabled, the compiler could
  turn an instruction sequence "ADDF32 MPYF32" into "MACF32" when it is
  not legal to do so. This bug will only occur if it just so happens
  that the compiler used R7 as one of the operands of the ADDF32
  instruction, which is not predictable by the user. The level of
  optimization as well as many other factors will affect whether or not
  the bug occurs, but it can't be predicted whether higher or lower
  levels will trigger the bug.
  
  Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.9, 6.4.0B1

Workaround:
  Add option --disable:ank_peep


===============================================================================
6. Current Known Issues
===============================================================================

The following 30 known issues exist for C2000 Code Generation Tools release
6.4.3 as of February 2015.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00008248
-------------------------------------------------------------------------------

Summary            : Compilers on PC will not work without TMP set
Affected Component : C/C++ Compiler (cl)
Duplicate Defects  : SDSCM00034609

Description:
  
  When compiling on the PC, the code generator cannot find the icode
  file produced by the parser if the environment variable TMP is no
  set. If TMP is set, then all appears well.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00008465
-------------------------------------------------------------------------------

Summary            : Language Conformance: crash because of void pointer
                     dereference
Affected Component : Parser

Description:
  Compiler generates multiple INTERNAL ERRORs when code like the following
  is compiled:
  
    void dr106_1(void *pv, int i)
    {
        *pv;
        i ? *pv : *pv;
        *pv, *pv;
    }

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00008534
-------------------------------------------------------------------------------

Summary            : Linker -xml_link_info option doesn't work when in a
                     command file
Affected Component : Linker

Description:
  
  The option --xml_link_info=file.xml does not work when it is
  placed inside a linker command file.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00008537
-------------------------------------------------------------------------------

Summary            : assembler expression ~(0x80000000) evaulates as
                     0x80000000
Affected Component : Assembler

Description:
  The following expression is evaluating incorrectly in the assembler:
  
    .eval ~(0x80000000), mask
  
  mask ends up getting assigned 0x80000000, whereas I expect it to be
  0x7FFFFFFF.
  It seems that any constant with bit 31 set will incorrectly return 0x80000000

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00008543
-------------------------------------------------------------------------------

Summary            : Forward reference in .space generates an internal error
Affected Component : Assembler

Description:
  If you attempt to assemble:
  
     .space 0+a
   b
   a .set 1
  
  the assembler will generate an internal error.
  
  This happens with v3.83 and v4.1.0B1 on Solaris.
  
  If you change the code to:
  
     .space a
   b
   b .set 1
  
  the correct error message is generated, 'Absolute, well-defined integer value
  expected'.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00008652
-------------------------------------------------------------------------------

Summary            : pow(2,x) has fairly significant rounding error
Affected Component : Runtime Support Libraries (RTS)

Description:
  The algorithm used for pow [exp(log(x),y)] is correct but sometimes leads
  to a precision error for some inputs, due to rounding bugs in floating-
  point handling.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00008928
-------------------------------------------------------------------------------

Summary            : Extern inline functions are not supported in the C/C++
                     Compiler
Affected Component : Parser
Duplicate Defects  : SDSCM00018364

Description:
  Users cannot create global accessible code with INLINE functions.
  The V3.00 compiler/code generator does not create globally accessible
  code for functions which are declared inline. A simple example is:
  
    inline int x() { return 1; }
    int y() {return 2;}
  
  When compiled with 'cl6x -k -c test.c', a warning is produced:
  
    'test.c', line 1: warning: function 'x' was declared but
    never referenced
  
  and the resulting assembler file (test.asm) does not
  contain any code for x(). The documentation states that code
  declared inline will be inlined in that module but global code will
  also be generated (section 2.10.3.2 in v3.00 C Compiler manual). The
  new compiler is overly aggressive in its optimizations. If y() is
  modified to call x() then code is generated for x() unless the
  optimizer is also invoked (by using -x2).

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00012183
-------------------------------------------------------------------------------

Summary            : Integer to pointer conversion doesn't truncate values
Affected Component : Code Generator

Description:
  I expect an expression involving a cast from integer to pointer type, where it
  is a narrowing conversion, to truncate the value of the integer to fit the
  pointer type. However, this doesn't seem to be happening for C28x in word
  mode. Conversion from integer to pointer is implementation-defined, but it
  works as I expect on the other targets. Possibly related is that fact that
  trg_alloc_offset() returns 0, but it should return 10 (bits) for C28x large
  model pointers.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00014430
-------------------------------------------------------------------------------

Summary            : calloc doesn't check arguments to make sure the
                     requested size is reasonable
Affected Component : Runtime Support Libraries (RTS)

Description:
  The function calloc() is required to return a pointer to memory representing
  "nelem" copies of "size" bytes, or NULL if the request cannot be satisfied.
  However, for some values of "nelem" and "size" (specifically when the result
  of nelem*size wraps around), calloc can return a pointer to an object that is
  not large enough, rather than NULL.
  
  For example, on a 32-bit target, if the user calls calloc(0x00010001,
  0x00010001), even though each argument by itself is reasonable, the request
  cannot be satisfied because the product is 0x000100020001, which exceeds
  size_t. (Note that we cannot check for overflow by checking if the product is
  less than either argument, which is commonly done for unsigned addition.)
  Arguably, we can try to claim that it is undefined behavior to make a call to
  calloc where the product would exceed size_t, but there doesn't seem to be
  anything in the standard which says so.
  
  The problem is worse on 16-bit targets, where calloc(0x0101, 0x0101) is enough
  to overflow size_t. It may not be obvious to the user that this overflows.
  
  Another concern is that it is hard to figure out whether a multiplication will
  overflow without having a double-width multiply available.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00016638
-------------------------------------------------------------------------------

Summary            : dis2000 does not handle disassembly of expanded BCND
                     instruction properly
Affected Component : Disassembler (dis)

Description:
  When C2XLP-specific instruction BCND is specified with multiple condition
  operands, the disassembly output does not show the expanded instruction
  sequence properly.
  
  Source code is attached, assemble with "asm2000 -v28 -m20 bcnd.asm", then
  disassemble with "dis2000 bcnd.obj > bcnd.dis". Observe disassembly of
  sequence of instructions that BCND expands to and you'll notice that the
  disassembly of the XB instruction encoding is not handled properly.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00016646
-------------------------------------------------------------------------------

Summary            : strcmp doesn't correctly handle values with uppermost
                     bit set
Affected Component : Runtime Support Libraries (RTS)

Description:
  The standard says: "The sign of a nonzero value returned by the comparison
  functions memcmp, strcmp, and strncmp is determined by the sign of the
  difference between the values of the first pair of characters (both
  interpreted as unsigned char) that differ in the objects being compared."
  However, this is a problem for 16-bit targets where the size of char is the
  same as the size of int. In this case, it's easy to mistakenly use an unsigned
  subtract to do the comparison and return it directly; this value can overflow.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00018691
-------------------------------------------------------------------------------

Summary            : Linker gives misleading warning when dot expressions
                     used in SECTION directive for .stack section
Affected Component : Linker

Description:
  Linker gives the warning:
  
  warning: creating ".stack" section with default size of 0x800; use the -stack
  option to change the default size
  
  even when the application does not link in boot code from RTS lib.
  
  A linker command file is used that contains a specialized SECTION directive
  for the ".stack" section. Because of a series of ". += <number>" assignments
  in the section spec, the linker is forced to increase the size of the .stack
  section to 0xc00. The linker is doing the correct thing by making a .stack
  section large enough to accommodate the dot expressions, but the diagnostic is
  misleading, as 0x800 isn't the final size of the .stack section.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00037411
-------------------------------------------------------------------------------

Summary            : C2000 assembler segmentation fault on RPTB with syntax
                     error
Affected Component : Assembler

Description:
  The C2000 assembler will issue a segmentation fault if given a RPTB
  instruction with faulty syntax. The syntax error is not issued. The attached
  file rptb_mov32_FAIL.asm illustrates the problem.
  
   cl2000 --float_support=fpu32 -v28 rptb_mov32_FAIL.asm
  
   INTERNAL ERROR: asm2000 experienced a segmentation fault while
   processing section .text file rptb_mov32_FAIL.asm line 23
  
   This is a serious problem. Please contact Customer
   Support with this message and a copy of the input file
   and help us to continue to make the tools more robust.
  
   >> Compilation failure
  
  We should see a syntax error on the RPTB instruction on line 21 of the
  input file.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00037836
-------------------------------------------------------------------------------

Summary            : boot-time copy table (BINIT) not implemented in C2000
                     RTS
Affected Component : Runtime Support Libraries (RTS)

Description:
  The BINIT feature to trigger a copy-in at boot time is not implemented in the
  RTS library.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00039054
-------------------------------------------------------------------------------

Summary            : Compiler reports a violation of Misra rule 12.8 for a
                     structure variable
Affected Component : C/C++ Compiler (cl)

Description:
  MISRA warning (MISRA-C:2004 12.8/R) The right-hand operand of a shift operator
  shall lie between zero and one less than the width in bits of the underlying
  type of the left-hand operand
  
  In the following code I get MISRA 12.8 warning on myVar = myStruct.aVar >> 16
  shift. Note that shift of unstructured variable myVar = myVar >> 16 is okay.
  
      typedef struct
      {
          unsigned long aVar;
      } myStruct_T;
  
      myStruct_T myStruct = {0xFFFFFFFFUL};
      unsigned long myVar;
  
      myVar = myStruct.aVar >> 16;
      myVar = myVar >> 16;
  
  
  

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00039236
-------------------------------------------------------------------------------

Summary            : Sometimes MISRA rule 19.15 is incorrectly emitted.  The
                     rule is about failing to use an inclusion guard in a
                     header file.
Affected Component : Parser

Description:
  In the attached test case rule 19.15 gets emitted even though the files
  mentioned do have proper inclusion guards.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00040934
-------------------------------------------------------------------------------

Summary            : Structure is not initialized correctly when using -o2 or
                     -o3 optimization
Affected Component : Optimizer

Description:
  There is a problem with the initialization of a structure using symbols
  generated in the linker command file. We use symbols generated in the linker
  cmd file using the dot operator. These symbols are used as an initial value
  for a class/struct with a constructor. In our case we want the difference of
  two addresses that the linker generates.
  
  When using optimization -o2 or -o3, the compiler generates .cinit entries
  instead of the constructor call. In those .init-entries it doesn't use the
  difference of the addresses; instead it uses the first symbol.
  
  When turning off optimization or using lower level of opt than -o2, the
  constructor calls are generated and the struct is initialized correctly.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00042344
-------------------------------------------------------------------------------

Summary            : Compiler generates internal error: illegal
                     initialization or segmentation fault
Affected Component : C/C++ Compiler (cl)

Description:
  The attached test case generates a segmentation fault when compiled with CGT
  6.1.x and 7.0.x.
  It generates the following error when compiled with 7.2.5 and 7.3.1 but does
  generate a .obj file.
  
  Build with: cl6x --gcc seg_fault.c
  
  >> INTERNAL ERROR: ILLEGAL INITIALIZATION
  
  This may be a serious problem. Please contact customer support with a
  description of this problem and a sample of the source files that caused this
  INTERNAL ERROR message to appear.
  
  Note: May lose variable initialization information
  
  ... continuing compilation ...
  
  User would like to know if there is a workaround.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00042434
-------------------------------------------------------------------------------

Summary            : Compiler misreports Misra warning 6.4 for bitfield
                     definitions
Affected Component : C/C++ Compiler (cl)
Duplicate Defects  : SDSCM00043122

Description:
  Compiler misreports Misra warning 6.4 for bitfield definitions.
  
  typedef unsigned int uint16_t;
  typedef unsigned int bool_t;
  #define FALSE ((bool_t)0U)
  #define TRUE ((bool_t)1U)
  
  typedef struct mystructtag
  {
    uint16_t u16_hw_rev1;
    bool_t bl_hardware_supported:1;       /* this violates rule 6.4 */ 
  } st_software_info_t ;
  
  This generates the warning:
  
  "misra_test.c", line 9: warning: (MISRA-C:2004 6.4/R) Bit fields shall only be
  defined to be of type unsigned int or signed int
  
  Related forum thread:
  http://e2e.ti.com/support/development_tools/compiler/f/343/t/147639.aspx
  
  According to Misra, this is not a Misra violation.
  http://www.misra-
  c.com/forum/viewtopic.php?f=62&t=1167&sid=6fd53ec7591d33a4fa1b38e975c580bc

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00042435
-------------------------------------------------------------------------------

Summary            : Compiler misreports Misra warning 10.1
Affected Component : C/C++ Compiler (cl)

Description:
  Compiler misreports Misra warning 10.1 with the following code:
  
  typedef unsigned int uint16_t;
  typedef unsigned int bool_t;
  #define FALSE ((bool_t)0U)
  #define TRUE ((bool_t)1U)
  
  typedef struct mystructtag
  {
    uint16_t u16_hw_rev1;
    bool_t bl_hardware_supported:1;       /* this violates rule 6.4 */ 
  } st_software_info_t ;
  
  
  void main(void)
  {
  
  uint16_t u16_rev1_min, u16_tmp;
  st_software_info_t sts_sw_info;
  u16_rev1_min = 900U;
  
  sts_sw_info.bl_hardware_supported = FALSE;
  
  if (sts_sw_info.bl_hardware_supported == FALSE)     /* this violates rule 10.1 */
  {
    /* do something... */
  }
  
  if (sts_sw_info.u16_hw_rev1 >= u16_rev1_min)       /* this violates rule 10.1 */
  {
    /* do something... */
  }
  
  u16_tmp = sts_sw_info.u16_hw_rev1;
  if (u16_tmp >= u16_rev1_min)       /* this does not violates rule 10.1 */
  {
    /* do something... */
  }
  
  The warning is:
  
  "misra_test.c", line 22: warning: (MISRA-C:2004 10.1/R) The value of an
  expression of integer type shall not be implicitly converted to a different
  underlying type if it is not a conversion to a wider integer type of the same
  signedness
  "misra_test.c", line 27: warning: (MISRA-C:2004 10.1/R) The value of an
  expression of integer type shall not be implicitly converted to a different
  underlying type if it is not a conversion to a wider integer type of the same
  signedness
  
  
  Related forum thread:http://e2e.ti.com/support/development_tools/compiler/f/3-
  43/t/147639.aspx
  
  Related Misra threads that say this is not a Misra violation:
  http://www.misra-
  c.com/forum/viewtopic.php?f=62&t=1167&sid=6fd53ec7591d33a4fa1b38e975c580bc
  http://www.misra-
  c.com/forum/viewtopic.php?f=66&t=1168&sid=6fd53ec7591d33a4fa1b38e975c580bc

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00043043
-------------------------------------------------------------------------------

Summary            : Array that is correctly initialized erroneously gets a
                     MISRA diagnostic about size not being specified
Affected Component : C/C++ Compiler (cl)

Description:
  For this input ...
  
      int16_t y[]={1,5,8};
  
  The compiler incorrectly issues this diagnostic ...
  
  "try1.c", line 2: warning: (MISRA-C:2004 8.12/R) When an array is declared
  with external linkage, its size shall be stated explicitly or
  defined implicitly by initialisation

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00044056
-------------------------------------------------------------------------------

Summary            : Compiler misreports Misra warning 10.1
Affected Component : C/C++ Compiler (cl)

Description:
  Compiler misreports MISRA warning 10.1/R for the following code.
  
  
  typedef enum _MyEnum { One, Two } MyEnum;
  MyEnum MyVariable;
  
  int foo(void)  
  {      
      int result = 1;         
      if (One == MyVariable)  // fails here with MISRA-C:2004 10.1/R      
      {          result = 2;      }          
      return result;  
  } 
  
  Our coding style convention requires that the variable is at the right hand
  side. Therefore I don't want to swap One and MyVariable, although that makes
  the warning to disappear.
  
  Is that a bug in the MISRA checker? If not, why is the comparison of two terms
  not commutable?

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00045452
-------------------------------------------------------------------------------

Summary            : Compiler misreports MISRA warning 17.6
Affected Component : C/C++ Compiler (cl)

Description:
  Compiler misreports MISRA warning 17.6 with the attached code.
  
  (MISRA-C:2004 17.6/R) The address of an object with automatic storage shall
  not be assigned to another object that may persist after the first object has
  ceased to exist
  
  In the following code, the assignment of &myLocalStruct->data to myDataPtr in
  myFunc has MISRA 17.6 reported. myDataPtr only persists for the duration of
  the function, and therefore does not persist longer than data passed into
  that function.
  
  typedef struct
  {
      uint8 data;
  } Struct_T;
  
  void myFunc(Struct_T *myLocalStruct);
  void main(void);
  
  void myFunc(Struct_T *myLocalStruct)
  {
      uint8 *myDataPtr;
  
      myDataPtr = &myLocalStruct->data; /* (MISRA-C:2004 17.6/R) reported here */
  }
  
  void main(void)
  {
      Struct_T myStruct = { 0U };
  
      myFunc(&myStruct);
  }

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00045473
-------------------------------------------------------------------------------

Summary            : Compiler misreports violation of Misra 9.2 for zero
                     initialization of structures
Affected Component : C/C++ Compiler (cl)

Description:
  Compiler misreports violation of Misra 9.2 for zero initialization of
  structures.
  
  (MISRA-C:2004 9.2/R) Braces shall be used to indicate and match the structure
  in the non-zero initialisation of arrays and structures
  
  
  typedef struct
  {
  unsigned char nModuleId;
  unsigned char nInstanceId;
  unsigned char nApiId;
  unsigned char nErrorId;
  } DetLog_T;
  
  DetLog_T sctDetLog_M[0x100] = { 0U };

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00048321
-------------------------------------------------------------------------------

Summary            : C2000 binary file IO does not handle char data with more
                     than 8-bits of data
Affected Component : Runtime Support Libraries (RTS)

Description:
  On C2000 a char is 16 bits, but the fread and fwrite functions will only read
  and write the lower 8 bits of every char. The problem looks to be in the
  __TI_writemsg/__TI_readmsg functions and the PACKCHAR macro. The macro only
  writes the lower 8 bits, but the function increments by 16 bits for every
  invocation of PACKCHAR. I'm not sure which piece is wrong.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00049284
-------------------------------------------------------------------------------

Summary            : Compiler misreports Misra warning 10.1
Affected Component : Parser

Description:
  Compiler misreports MISRA warning 10.1/R for the following code.
  
  typedef enum _MyEnum { One, Two } MyEnum;
  MyEnum MyVariable;
  
  int foo(void)  
  {      
      int result = 1;        
      if (One == MyVariable)  // fails here with MISRA-C:2004 10.1/R      
      {          result = 2;      }          
      return result;  
  } 

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00050131
-------------------------------------------------------------------------------

Summary            : Local struct with non-constant initializer treated as
                     static scope variable
Affected Component : Parser

Description:
  We've discovered a problem where the C++ compiler places a local structure
  variable not on the stack but in the data segment, as if it was a static
  structure. The problem is especially insidious because the issue will only
  have an impact on re-entrance.
  
  The problem seems to occur only for C++ files, and only if the structure
  initializer list contains a variable. Constant initializer lists do not
  trigger the issue.
  
  The structure in the first function will be allocated on the stack, but the
  structure in the second will be compiled as if it was declared static.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00050540
-------------------------------------------------------------------------------

Summary            : CLA Assembler accepts invalid instruction MMOV32 mem,
                     MRn, COND
Affected Component : Assembler

Description:
  The CLA assembler accepts and invalid instruction and encodes a different
  instruction, generating an object file. See the attached assembly and
  disassembly output. There is no conditional MMOV32 to a memory destination.
  The only valid conditional MMOV32 instructions have register (MRn)
  destinations.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00051315
-------------------------------------------------------------------------------

Summary            : The type _Bool is illegal by default only for CLA code
Affected Component : C/C++ Compiler (cl)

Description:
  Any use of the built-in type _Bool is not allowed in CLA code. But it is
  allowed in C code.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00051406
-------------------------------------------------------------------------------

Summary            : Bool Support on CLA Compiler as part of STDBOOL.h
Affected Component : C/C++ Compiler (cl)

Description:
  When inlcuded in a *.cla file _Bool is not defined as needs to be defined in
  CLA customer code. This is not the ideal scenario.
  
  Please support Bool in stdint.h for CLA. Filed this as a bug as a similar
  request was submitted last year for enhancement.
  
  #ifndef _Bool
  #define _Bool uint16_t
  #endif