TMS470 C/C++ CODE GENERATION TOOLS
5.2.2 January 2015
Defect History

-------------------------------------------------------------------------------
Table of Contents
-------------------------------------------------------------------------------
1. Defects fixed in TMS470 Code Generation Tools release 5.2.2
2. Defects fixed in TMS470 Code Generation Tools release 5.2.1
3. Defects fixed in TMS470 Code Generation Tools release 5.2.0
4. Defects fixed in TMS470 Code Generation Tools release 5.2.0B1
5. Current Known Issues


===============================================================================
1. Defects fixed in TMS470 Code Generation Tools release 5.2.2
===============================================================================

The following 4 defects were fixed in TMS470 Code Generation Tools release
5.2.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           : 5.2.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 SDSCM00051238
-------------------------------------------------------------------------------

Summary            : The Cortex-R4 silicon defect for VMRSEQ APSR_nzcv, FPSCR
                     is incorrectly warned about if the destination is an ARM
                     register

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

Release Notes:
   The warning incorrectly triggers for cases where the destination register for
   the VMRS instruction is not APSR_nzcv.

Workaround:
  None

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

Summary            : Output section splitting creates a zero-length section

Fixed in           : 5.2.2
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 TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 -
  5.1.9, 5.0.4.102, 5.2.0B1 - 5.2.1

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

Summary            : Linker mistakenly issues output section warning
                     diagnostic for sections pre-bound to hard coded
                     addresses

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

Release Notes:
  The warning is incorrectly issued for bound sections. Bound sections,
  created by the location pragma, are created by default by the linker, but
  since this is part of the implementation the linker should not issue a
  warning.
  
  Defect occurs in TMS470 Compiler versions: 5.2.0B1 - 5.2.1

Workaround:
  Ignore the warning


===============================================================================
2. Defects fixed in TMS470 Code Generation Tools release 5.2.1
===============================================================================

The following defect was fixed in TMS470 Code Generation Tools release 5.2.1,
released December 2014.

-------------------------------------------------------------------------------
FIXED SDSCM00050764
-------------------------------------------------------------------------------

Summary            : Bound function has incorrect address in DWARF debug info

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

Release Notes:
  The TI compiler allows a function to be bound to a specific address,
  usually with "#pragma location". There was a bug in the way the TI
  assembler recorded the DWARF debugging information for a bound
  function that corrupted the DWARF debugging information. This would
  cause CCS to report "no source available" when stepping attempting to
  step into such a function.
  
  Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.9,
  5.0.4.102, 5.2.0B1 - 5.2.0

Workaround:
  Set a breakpoint at the bound function and run to it, rather than
  attempting to step into it.


===============================================================================
3. Defects fixed in TMS470 Code Generation Tools release 5.2.0
===============================================================================

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

-------------------------------------------------------------------------------
FIXED SDSCM00051039
-------------------------------------------------------------------------------

Summary            : 64-bit divide routine does not return results as
                     documented

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

Release Notes:
  The ARM EABI run-time ABI requires that __aeabi_ldivmod return one of
  a specific set of values when the divisor is zero. __aeabi_ldivmod is
  to return the value of calling __aeabi_ldiv0 with an argument of
  LLONG_MIN, LLONG_MAX, or 0, when the dividend is negative, positive,
  or zero, respectively. However, for some negative values, the
  function would instead return the dividend.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 -
  5.1.8, 5.0.4.102, 5.2.0B1

Workaround:
  Don't rely on integer division by zero to return any reasonable value.

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

Summary            : Output section splitting creates a zero-length section

Fixed in           : 5.2.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 TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 -
  5.1.8, 5.0.4.102, 5.2.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           : 5.2.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.

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

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

Fixed in           : 5.2.0
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.


===============================================================================
4. Defects fixed in TMS470 Code Generation Tools release 5.2.0B1
===============================================================================

The following 71 defects were fixed in TMS470 Code Generation Tools release
5.2.0B1, released October 2014.

-------------------------------------------------------------------------------
FIXED SDSCM00013456
-------------------------------------------------------------------------------

Summary            : fgets in _IONBF mode does not respect size limit

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

Release Notes:
  The second argument to fgets() is the maximum number of chars to read.
  In _IONBF mode, fgets() reads until end-of-line, potentially
  overrunning the input buffer. For example:
  
  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>
  #include <assert.h>
  
  main()
  {
      FILE *f = fopen("tst.txt", "r");
      char buffer[100];
      int counter = 0;
  
      setvbuf(f, NULL, _IONBF, 0);
  
      while (fgets(buffer, 5, f) != NULL)
      {
          printf("[%s]\n", buffer);
          switch (counter++)
          {
              case 0: assert(!strcmp(buffer, "aaaa")); break;
              case 1: assert(!strcmp(buffer, "bbbb")); break;
              case 2: assert(!strcmp(buffer, "cccc")); break;
          }
      }
  
      assert(feof(f));
  
      puts("PASS");
  }
  
  With tst.txt having (with no trailing newline):
  
  aaaabbbbcccc
  
  Defect occurs in TMS470 Compiler versions: 2.40 - 2.71, 4.1.0B1 - 4.1.7,
  2.54.203 - 2.54.209, 2.54.03 - 2.54.129, 4.3.0B1, 4.4.0B1 - 4.4.18, 4.5.0B1 -
  4.5.2, 4.4.10.100 - 4.4.10.120, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210,
  4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 4.10.0B1,
  5.0.0B1 - 5.0.6, 5.1.0B1 - 5.1.1

Workaround:
  Do not use _IONBF mode

-------------------------------------------------------------------------------
FIXED SDSCM00029483
-------------------------------------------------------------------------------

Summary            : asm470 crash on bad asm instruction

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

Release Notes:
  The instruction in this test case (" MOV R0 #0") is missing a comma;
  the assembler discarded the #0 part as extra garbage, so the
  instruction looks like only one operand is provided. A function in
  the assembler which is checking whether the instruction can be a
  THUMB2 instruction, but doesn't check that the operand is non-NULL,
  leading to a NULL pointer dereference, which will crash the assembler.
  
  Defect occurs in TMS470 Compiler versions: 4.4.0 - 4.4.18, 4.5.0 - 4.5.2,
  4.4.10.100 - 4.4.10.120, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 -
  4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.200 - 4.7.1.202, 4.10.0B1, 5.0.0B1 -
  5.0.6, 5.1.0B1 - 5.1.1

Workaround:
  Provide the correct number of operands to this kind of instruction,
  separated by commas where required. You can quickly find most of the
  errors in the instructions at issue by assembling in ARM mode, where
  the appropriate error messages will appear without the crash.

-------------------------------------------------------------------------------
FIXED SDSCM00043605
-------------------------------------------------------------------------------

Summary            : Linker segfaults linking partially linked file when
                     partial link includes RTS library, ELF, and exceptions

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : ELF Linker

Release Notes:
  This bug will be fixed on C6000 7.5.0, MSP430 4.3.0, and ARM 5.2.0 releases,
  and later. The bug will not be fixed on older releases due to technical
  difficulties.
  
  Table driven exception handling (TDEH) is not supported during a partial link
  where sections are collected into an output section. During a partial link, if
  no SECTIONS directive is used, all input sections are passed through as output
  sections. In this case TDEH should work fine after the final link. If there is
  a SECTIONS directive for the partial link, then TDEH will not work and will
  most likely cause an INTERNAL ERROR during the final link.

Workaround:
  Do not use a SECTIONS directive when performing a partial link and TDEH
  is enabled.

-------------------------------------------------------------------------------
FIXED SDSCM00043860
-------------------------------------------------------------------------------

Summary            : Printf format %#06x prints zeros in the wrong place

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : C/C++ Compiler (cl)
Duplicate Defects  : SDSCM00008251

Release Notes:
  When the # and 0 flags are both used with the x conversion specifier, any
  extra 0 characters added to fill up the precision should be added after
  the 0x prefix, but the TI library added them before the 0x prefix.
  
  Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2,
  4.4.10.100 - 4.4.10.120, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
  4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.6,
  5.1.0B1 - 5.1.1

Workaround:
  Avoid using both # and 0 flags when using the x conversion specifier.

-------------------------------------------------------------------------------
FIXED SDSCM00044118
-------------------------------------------------------------------------------

Summary            : Inline jump table mistakenly gets .clink attached

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

Release Notes:
  The compiler sometimes generates jump tables to implement switches.
  Usually, these jump tables are in a different section, and each
  section needs to be handled with the appropriate choice of .retain,
  .clink, or neither. In this case, as a special optimization, the jump
  table is actually part of the function text, and is not in its own
  distinct section. In this case, the compiler should not emit any
  .retain or .clink, but it emits .clink. The assembler detects this
  and (depending on the ABI) emits a warning that the .clink is ignored.
  
  Defect occurs in TMS470 Compiler versions: 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 -
  4.9.9, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.6, 5.1.0B1 - 5.1.2

Workaround:
  You can ignore this warning.

-------------------------------------------------------------------------------
FIXED SDSCM00045173
-------------------------------------------------------------------------------

Summary            : Missing qsort and bsearch implementations for comparison
                     functions with C++ linkage

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

Release Notes:
  The C++ standard requires two distinct prototypes for qsort, one for
  comparison functions with C linkage, and one for comparison functions
  with C++ linkage. The C++ linkage implementation was missing, which
  would lead to an incompatible parameter error when trying to use qsort in
  C++ with a comparison function that has C++ linkage.
  
  Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 -
  4.5.2, 4.4.10.100 - 4.4.10.119, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210,
  4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 -
  5.0.4, 5.1.0B1

Workaround:
  Declare the comparison function extern "C"

-------------------------------------------------------------------------------
FIXED SDSCM00045357
-------------------------------------------------------------------------------

Summary            : Linker generates unhandled exception when generating
                     dynamic library

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : Linker

Release Notes:
  Linker sometimes generates unhandled exception when generating dynamic library
  
  The ELF executable was statically linked because it could not be dynamically
  linked. The executable should not have been statically linked. The linker now
  emits an error when an executable cannot be statically or dynamically linked.

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00045373
-------------------------------------------------------------------------------

Summary            : EXIDX section for alias function leads to INTERNAL ERROR
                     unhandled exception

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : Linker

Release Notes:
  If all of --exceptions, --unused_section_elimination=off, and
  --retain=.ARM.EXIDX are used, and the compiler turns a C++ function into
  an alias (this is a TI-specific optimization), it is possible for the
  linker to retain the EXIDX section for the alias function but not the
  alias function itself, which leads to an internal error.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.7, 5.0.0B1 -
  5.0.4, 5.1.0B1

Workaround:
  Do not use either --unused_section_elimination=off or
  --retain=.ARM.EXIDX. Neither one should be necessary in a
  properly-functioning linker, and both make the target footprint larger.

-------------------------------------------------------------------------------
FIXED SDSCM00045417
-------------------------------------------------------------------------------

Summary            : bool and _Bool are not defined correctly in strict ANSI
                     C mode

Fixed in           : 5.2.0B1
Severity           : S3 - Minor
Affected Component : C/C++ Compiler (cl)
Duplicate Defects  : SDSCM00048227, SDSCM00048226

Release Notes:
  The size and type of "bool" and "_Bool" must be the same in all modes
  so that declarations of the same object in different modules are
  compatible. However, in strict ANSI C89 mode, stdbool.h defines _Bool
  as "unsigned int," which means a C++ module using bool and a C module
  including stdbool.h and using bool are using incompatible types.
  
  _Bool and stdbool.h are C99 features, so a strictly-conforming C89
  program does not use them, but the TI compiler provides them as an
  extension. This would cause a problem when attempting to mix C++
  files and C files which both declare
  
  The ARM EABI Procedure Call Standard for the ARM Architecture (ARM IHI
  0042D) section 7.1.1 ("Arithmetic Types") requires that both C++ bool
  and C99 _Bool be unsigned byte types. However, the TI toolset does
  not conform to that requirement.
  
  Defect occurs in TMS470 Compiler versions: 4.4.0 - 4.4.18, 4.5.0B1 - 4.5.2,
  4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
  4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.9, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.8,
  5.1.0B1 - 5.1.3

Workaround:
  The compiler and library now agree on a single definition of bool and
  _Bool in all modes; its format is equivalent to "unsigned char."
  Unfortunately, this represents a backward incompatibility with older
  object files which match all of these conditions:
  
  - C source code
  - includes stdbool.h
  - compiled in strict C89 mode (the default in older compilers)
  - module interface uses type _Bool or bool (i.e. a global variable,
    function argument, or function return value of type derived from
    bool, or struct containing a type derived from bool.)
  
  To work around the problem, either recompile with the latest version
  of the compiler, or ensure that you aren"t using any _Bool or bool
  objects in the module interface.

-------------------------------------------------------------------------------
FIXED SDSCM00046084
-------------------------------------------------------------------------------

Summary            : Hex utility incorrectly picks empty section over a
                     non-empty section with duplicate name

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

Release Notes:
  There can be duplicate section names in an object file. When
  converting such a file, the hex converter will emit a warning and fail
  to convert the section. For this test case, it is sufficient to have
  the hex converter ignore zero-length sections. Handling duplicate
  section names, neither of which are empty, will require some redesign,
  and will be pursued as a separate effort. This defect report has been
  re-purposed as the more targeted fix of ignoring zero-length sections.
  See SDSCM00046936 for the ongoing work to handle duplicate section
  names for non-empty sections.
  
  Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 -
  4.5.2, 4.4.10.100 - 4.4.10.119, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210,
  4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 5.0.0B1 -
  5.0.4, 5.1.0B1

Workaround:
  Use a different output section for the duplicate .text section

-------------------------------------------------------------------------------
FIXED SDSCM00046177
-------------------------------------------------------------------------------

Summary            : ELF section header table not guaranteed to be aligned

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

Release Notes:
  I conclude that the linker is generating something wrong when creating
  relocatable output that gets corrected when it later generates executable
  output. A further observation: after linking the relocatable linker
  output to form an executable, I note that the section headers are
  misaligned (at offset 0xaca from the start of the file).
  This appears to break the alignment rule from:
  http://www.sco.com/developers/gabi/2003-12-17/ch4.intro.html#file_format
  
  "All data structures that the object file format defines follow the
  ``natural'' size and alignment guidelines for the relevant class. If
  necessary, data structures contain explicit padding to ensure 8-byte
  alignment for 8-byte objects, 4-byte alignment for 4-byte objects, to
  force structure sizes to a multiple of 4 or 8, and so forth. Data also
  have suitable alignment from the beginning of the file. Thus, for
  example, a structure containing an Elf32_Addr member will be aligned on a
  4-byte boundary within the file. " Section headers contain Elf32_Addr
  members, and so should be aligned on a 4-byte boundary (which 0xaca
  isn't). It appears that the compiler is failing to pad the size of the
  string table to ensure the alignment of the following areas. You can see
  that the alignment of the section headers depends on the size of the
  string table by changing the function name to 'main2'. This generates an
  output file where the section header offset is 534. The misaligned
  section headers lead to a CCS crash (SDSCM00046176).
  
  Defect occurs in TMS470 Compiler versions: 4.9.0 - 4.9.8, 5.0.0B1 - 5.0.4,
  5.1.0B2 - 5.1.0B1

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00046231
-------------------------------------------------------------------------------

Summary            : DATA_ALIGN should not be able to reduce alignment below
                     default array alignment

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

Release Notes:
  With the following program:
  
  #pragma DATA_SECTION(array, 4)
  int array[100];
  
  Observe that the alignment of array is 32, should be 64.
  
  The DATA_ALIGN pragma should not cause an array to have an
  alignment that is less than the default array alignment. The DATA_ALIGN
  pragma is ignored if it attempts to do so.

Workaround:
  Use the DATA_ALIGN pragma with an array alignment value of at least 8 for
  C64x+

-------------------------------------------------------------------------------
FIXED SDSCM00046351
-------------------------------------------------------------------------------

Summary            : Assembler mishandles certain combinations of S and
                     condition codes

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

Release Notes:
  When using the UAL syntax for an instruction which both sets the
  status register and is conditional, the assembler would get confused
  when trying to distinguish S used as "sets status" versus S used as
  "signed" in SB and SH. It would also get confused when using HS with
  MOV or LD.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.9, 5.1.0B1 -
  5.1.7, 5.0.4.102

Workaround:
  Use the pre-UAL syntax

-------------------------------------------------------------------------------
FIXED SDSCM00046812
-------------------------------------------------------------------------------

Summary            : Instructions are placed in the wrong order

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

Release Notes:
  In rare cases, incorrect analysis by the compiler may indicate that two
  memory or stack accesses are unrelated when they actually refer to the
  same object. If this occurs, the compiler may schedule an access
  incorrectly.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.8, 5.0.0B1 -
  5.0.4, 5.1.0B1

Workaround:
  No definite workaround exists. However, changing the optimization level
  may avoid the problem by changing the stack or memory layout.

-------------------------------------------------------------------------------
FIXED SDSCM00046816
-------------------------------------------------------------------------------

Summary            : Excessive compile time - Optimizer hangs

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Classification     : Performance
Affected Component : Optimizer

Release Notes:
  A program containing large structs containing many fields, especially if
  those fields are of type char, may require excessive time to compile.
  The compiler must check all those fields for potential aliases, and does
  so inefficiently.
  
  Defect occurs in TMS470 Compiler versions: 2.209e, 2.40.beta - 2.71, 4.1.0B1 -
  4.1.7, 2.54.02 - 2.54.209, 2.54.03 - 2.54.129, 2.202.03e - 2.202.15e, 4.4.0B1
  - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.119, 4.6.0B1 - 4.6.6,
  4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201
  - 4.7.1.202, 5.0.0B1 - 5.0.4, 5.1.0B1

Workaround:
  None known.

-------------------------------------------------------------------------------
FIXED SDSCM00046848
-------------------------------------------------------------------------------

Summary            : NOINIT keyword may be ignored

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : ELF Linker
Duplicate Defects  : SDSCM00047211

Release Notes:
  The linker command file keyword type(NOINIT) will be ignored in the ARM
  v5.0.4 and MSP430 v4.1.5 compilers. The changes made to fix
  SDSCM00045211 were incorrect, causing sections marked NOINIT in the
  linker command file to be initialized via the cinit mechanism for EABI.
  
  Defect occurs in TMS470 Compiler versions: 5.0.4, 5.1.0B1

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00046849
-------------------------------------------------------------------------------

Summary            : stdin stdout stderr macros need to be usable without
                     using namespace std for _ftable

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : Runtime Support Libraries (RTS)
Duplicate Defects  : SDSCM00045792, SDSCM00043348

Release Notes:
  stdin, stdout, and stderr are macros involving the identifier
  std::_ftable. As a macro, the namespace is not specified as you would
  for a type or variable (std::size_t). When cstdio is included, these
  macros are defined and should be usable without a using declaration
  putting std::_ftable in the global namespace.
  
  Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 -
  4.5.2, 4.4.10.100 - 4.4.10.119, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210,
  4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 5.0.0B1 -
  5.0.4, 5.1.0B1

Workaround:
  Include stdio.h instead of cstdio

-------------------------------------------------------------------------------
FIXED SDSCM00046910
-------------------------------------------------------------------------------

Summary            : Using an invalid option with valid hex command file
                     causes SIGSEGV

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

Release Notes:
  Using an invalid option with valid hex command file causes a
  segmentation fault.
  
  Defect occurs in TMS470 Compiler versions: 4.6.0B1 - 4.6.6, 4.7.0B1 - 4.7.1,
  4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.4, 5.1.0B1

Workaround:
  Fix or eliminate the invalid option.

-------------------------------------------------------------------------------
FIXED SDSCM00047206
-------------------------------------------------------------------------------

Summary            : Calls to isnan in C++ program lead to undefined symbol
                     error

Fixed in           : 5.2.0B1
Severity           : S1 - Critical / PS
Affected Component : Runtime Support Libraries (RTS)

Release Notes:
  The definition of isnan and isinf in the header file math.h eventually
  refers to library functions, and in C++ needs to refer to these functions
  in a namespace. The user should be able to use isnan and isinfo without
  refering to the std namespace.
  
  Defect occurs in TMS470 Compiler versions: 4.8.0B1, 4.9.0B1 - 4.9.8, 5.0.0B1 -
  5.0.4, 5.1.0B1

Workaround:
  Add "using namespace std;" after including math.h

-------------------------------------------------------------------------------
FIXED SDSCM00047263
-------------------------------------------------------------------------------

Summary            : different binaries after compilation

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

Release Notes:
  When address-space layout randomisation is used by the OS, as is usually
  the case for modern Windows and Linux versions, compiler output may be
  different once in a while on the same input. It isn't predictable; in
  the given test case, usually only a handful of iterations are needed
  before a difference appears, but sometimes it takes a couple dozen.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.8, 4.10.0B1, 5.0.0B1
  - 5.0.5, 5.1.0B1

Workaround:
  "setarch -R" appears to work around the problem on Linux. There are
  apparently add-on tools for Windows that accomplish the same, or one can
  fiddle with the registry, but I don't have details.

-------------------------------------------------------------------------------
FIXED SDSCM00047502
-------------------------------------------------------------------------------

Summary            : linker fails with internal error if .cinit and .data are
                     in the same GROUP

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : Linker

Release Notes:
  The internal error was caused by attempting to place .cinit in a GROUP
  with .data in an ELF file. This is not a recommended practice. The fix
  will allow .cinit and .data in a GROUP only if .data preceeds .cinit. In
  that case, compression of cinit records can not be performed. If .cinit
  is placed before .data in a GROUP, a user level error is reported.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0 - 4.9.8, 5.0.0B1 - 5.0.6,
  5.1.0B1 - 5.1.1

Workaround:
  Move .cinit so that it is not in any GROUP

-------------------------------------------------------------------------------
FIXED SDSCM00047666
-------------------------------------------------------------------------------

Summary            : Definition of SIZE_MAX is wrong

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

Release Notes:
  The definition of SIZE_MAX was incorrectly specified as the largest
  signed integer value. It is now defined as the largest unsigned integer
  value.
  
  Defect occurs in TMS470 Compiler versions: 4.6.0B1 - 4.6.6, 4.9.0B1 - 4.9.9,
  5.0.0B1 - 5.0.7, 5.1.0B1 - 5.1.3

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00047883
-------------------------------------------------------------------------------

Summary            : bsearch failure when using -pr relaxed ANSI mode or
                     --gcc mode from C++

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : C/C++ Compiler (cl)
Duplicate Defects  : SDSCM00047268

Release Notes:
  In relaxed mode calling bsearch from C++ results in an infinite loop.

Workaround:
  A workaround is to use --strict_ansi.

-------------------------------------------------------------------------------
FIXED SDSCM00047963
-------------------------------------------------------------------------------

Summary            : Incorrect float compare when one value is equal to the
                     other but with all zero low word

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

Release Notes:
  The problem here is that the __aeabi_cdcmple function has a bug when comparing
  two float values that have identical upper 32 bits, but differ in the lower 32
  bits, and one of them has all 0's in the lower 32 bits. The last thing that
  happens in __aeabi_cdcmple is a comparison of the lower bits to 0, which sets
  the Z bit, which is incorrect - we want C=1 Z=0

Workaround:
  Use 32-bit float, or link against the RTS from another vendor's EABI
  toolchain.

-------------------------------------------------------------------------------
FIXED SDSCM00048263
-------------------------------------------------------------------------------

Summary            : _sxtb16(x, 0) in Thumb-2 mode gives INTERNAL ERROR: no
                     match

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

Release Notes:
  When using the intrinsic _sxtb16 with 0 as the second argument in
  Thumb-2 mode (Cortex-M4 or Cortex-A8/R4 in thumb mode), the compiler
  will abort with an internal error message.
  
  Defect occurs in TMS470 Compiler versions: 5.1.0B1 - 5.1.1

Workaround:
  For Cortex-A8/R4, compile the function in ARM mode. No practical
  workaround for Cortex-M4.

-------------------------------------------------------------------------------
FIXED SDSCM00048272
-------------------------------------------------------------------------------

Summary            : Compiler uses non-UAL syntax for SWI in UAL mode

Fixed in           : 5.2.0B1
Severity           : S3 - Minor
Affected Component : Code Generator

Release Notes:
  When compiling for a pre ARMv7 (Cortex) architecture in Thumb mode, the
  compiler will emit an SWI for the _call_swi intrinsic, and the assembler
  will emit a warning that SWI is not UAL form.
  
  Defect occurs in TMS470 Compiler versions: 5.1.0B1 - 5.1.1

Workaround:
  Ignore the warning

-------------------------------------------------------------------------------
FIXED SDSCM00048289
-------------------------------------------------------------------------------

Summary            : Errors of the linker due to the difference in version of
                     CGT

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : Linker
Duplicate Defects  : SDSCM00048621

Release Notes:
  The fix for SDSCM00044393 was intended to allow the following linker
  command file syntax:
  SECTIONS
  {
     OUTSECT_NAME  MEMORY_RANGE_NAME
  }
  
  The Assembly Language Tools User Guide erroneously stated that this
  syntax was accepted. However, allowing the above syntax introduces
  ambiguity in the linker command file grammar, which caused previously
  accepted command files to produce errors, resulting in this bug
  (SDSCM00048289).
  
  This change removes the fix applied for SDSCM00044393. The above syntax
  will no longer be accepted. The linker will now issue a warning if an
  output section is specified but no placement information is found for
  it. The documentation will be updated to specify that load allocation
  may be specified with the syntax "load = allocation" or "> allocation".
  
  The above syntax will result in a warning that no placement was specified
  for OUTSECT_NAME and a default placement will be applied. Valid linker
  command files that were rejected due to the ambiguity will now be accepted.

Workaround:
  The problem can be avoided by using memory range names that are different from
  section names. For example, this linker command file may cause the error
  because "RAM" is both a memory range name and a section name:
  
  MEMORY {
      RAM :
  }
  
  SECTIONS {
      <other section directives>
     RAM  : > RAM
  }
  
  But this one would not cause the error:
  
  MEMORY {
      RAM_MEM :
  }
  
  SECTIONS {
      <other section directives>
     RAM  : > RAM_MEM
  }
  
  Also okay:
  
  MEMORY {
      RAM :
  }
  
  SECTIONS {
      <other section directives>
     RAM_SECT  : > RAM
  }

-------------------------------------------------------------------------------
FIXED SDSCM00048419
-------------------------------------------------------------------------------

Summary            : ARM compiler should set the Tag_PCS_config build
                     attribute to 1, meaning bare metal PCS.

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

Release Notes:
  The TI compiler will now set the PCS_config build attribute to value "1" aka
  "bare platform". It will accept tag values 0 (undefined) and 1 and mix them
  without a diagnostic message to ensure older object files can still be linked
  with newer files since this is a summary attribute and the critical checks
  occur on the attributes following it.

Workaround:
  Use --diag_warning=16004 to downgrade the diagnostic to a warning if one is
  encountered.

-------------------------------------------------------------------------------
FIXED SDSCM00048440
-------------------------------------------------------------------------------

Summary            : SIGSEGV when using MISRA checks on code with an
                     anonymous struct

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : Parser
Duplicate Defects  : SDSCM00050700

Release Notes:
  When using MISRA checking on code that contains an anonymous struct, the
  parser will crash with a SIGSEGV. Note that anonymous structs are not
  legal in strict ANSI mode, and MISRA emits a warning if strict ANSI mode
  is not used.
  
  Defect occurs in TMS470 Compiler versions: 4.8.0B1, 4.9.0B1 - 4.9.9, 5.0.0B1 -
  5.0.7, 5.1.0B1 - 5.1.2

Workaround:
  Do not use anonymous structs or unions when using MISRA

-------------------------------------------------------------------------------
FIXED SDSCM00048448
-------------------------------------------------------------------------------

Summary            : CRC algorithm is not correct for little endian parts

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : Linker

Release Notes:
  When using CRC algorithm TMS570_CRC64_ISO For little endian parts,
  each 64-bit chunk of data needs to be byte swapped before calculating
  the CRC. The linker was not correctly computing the CRC.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.7,
  5.1.0B1 - 5.1.2

Workaround:
  No practical workaround

-------------------------------------------------------------------------------
FIXED SDSCM00048498
-------------------------------------------------------------------------------

Summary            : MISRA-C rule 12.8 incorrectly reported for an expression
                     like ((uint32_t)2U << 8U);

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

Release Notes:
  A violation warning for the MISRA 12.8 rule was reported for the
  expression: ((uint32_t)2U << 8U);
  
  The MISRA 12.8 rule states that "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". The underlying type is
  determined by section 6.10 of the MISRA Guidelines. For a literal it is
  defined as being the smallest type of the same sign that can represent
  the literal, so for 2U the type is unsigned char. In that case the
  diagnostic is correct. However, the cast to uint32_t should make the
  underlying type unsigned int, making the operation legal.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.8,
  5.1.0B1 - 5.1.4

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00048513
-------------------------------------------------------------------------------

Summary            : ARM linker generates an overflow error for R_ARM_THM_PC8
                     relocation

Fixed in           : 5.2.0B1
Severity           : S3 - Minor
Affected Component : Linker

Release Notes:
  The IAR ARM compiler produces the R_ARM_THM_PC8 relocation for 16-bit
  literal load instructions. The TI compiler does not produce this relocation
  type. It should be safe to ignore the overflow diagnostic in this case.
  
  Defect occurs in TMS470 Compiler versions: 2.41.beta - 2.71, 4.1.0 - 4.1.7,
  2.54.205 - 2.54.209, 2.54.110 - 2.54.129, 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2,
  4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
  4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.9, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.7,
  5.1.0 - 5.1.2

Workaround:
  There is no workaround. You should be able to ignore the error.

-------------------------------------------------------------------------------
FIXED SDSCM00048534
-------------------------------------------------------------------------------

Summary            : String constant with indexing operator causes compiler
                     to emit panic error message and quit

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

Release Notes:
   An indexed expression without a variable like the one below was parsed
   incorrectly when appearing on the right hand side of an assignment:
  
   long x = "abcd"[0];
  
  

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00048712
-------------------------------------------------------------------------------

Summary            : ARM assembler seg faults on certain input

Fixed in           : 5.2.0B1
Severity           : S3 - Minor
Affected Component : Assembler
Duplicate Defects  : SDSCM00049517

Release Notes:
  The problem is that the assembly instruction LDR r0,0x40004000 is not legal.
  The assembler believes 0x40004000 is a symbol because the user did not put a
  '#' in front of it. Adding the '#' produces the correct error: "Invalid
  addressing mode". This is still a defect because the assembler sshould not seg
  fault on a bad instruction.

Workaround:
  Add the '#' in front of the 0x40004000 to produce the correct "Invalid
  addressing mode" error.

-------------------------------------------------------------------------------
FIXED SDSCM00048747
-------------------------------------------------------------------------------

Summary            : Using END(sym_name) or SIZE(sym_name) on .cinit can
                     cause link to fail

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : ELF Linker

Release Notes:
  When the compression is performed, the size of the parent collection needs to
  be updated.

Workaround:
  Avoid the use of the END() or SIZE() operators for .cinit or other
  compressed sections.

-------------------------------------------------------------------------------
FIXED SDSCM00048891
-------------------------------------------------------------------------------

Summary            : Should reject MUL instruction with constant operand in
                     T2 mode

Fixed in           : 5.2.0B1
Severity           : S3 - Minor
Affected Component : Assembler

Release Notes:
  For Thumb 2, the instructions MUL, MLA, and MLS may not accept a constant
  (immediate) value as an operand; the operands must be registers.
  However, the linker fails to emit an error for the source registers;
  instead, it silently encodes an incorrect register.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.9, 5.1.0B1 -
  5.1.7, 5.0.4.102

Workaround:
  Don't use the illegal instruction "MUL R4, R4, #5". Thumb 2 doesn't have
  a MUL which accepts a constant argument.

-------------------------------------------------------------------------------
FIXED SDSCM00048936
-------------------------------------------------------------------------------

Summary            : Linker generated ECC is not correct for F035 devices

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : Linker

Release Notes:
  When the input required padding due to the mirroring scheme, the
  algorithm failed to take the length of padding into account when
  computing the ECC values, leading to incorrect ECC data. This
  manifested in the F035 mirroring scheme.
  
  Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.7, 5.1.0B1 - 5.1.3

Workaround:
  Use the NowECC tool to generate ECC for F035

-------------------------------------------------------------------------------
FIXED SDSCM00049035
-------------------------------------------------------------------------------

Summary            : Value of "weak" global incorrectly propagated into
                     function

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

Release Notes:
  When using a weak symbol def with an initializer, the weak symbol could
  be pre-empted with a strong symbol from another compilation unit. The
  optimizer is not entitled to assume that weak definition is actually
  used, and thus cannot assume its initializer is the actual value it has
  at runtime. However, the optimizer mistakenly copied the value of the
  initializer into the function where the variable was used, which led to
  an error when the symbol was pre-empted by a strong symbol with a
  different value.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121,
  4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 -
  5.0.7, 5.1.0B1 - 5.1.2

Workaround:
  Do not use an explicit initializer with weak symbol definitions, or use
  optimization level -o2 or lower.

-------------------------------------------------------------------------------
FIXED SDSCM00049110
-------------------------------------------------------------------------------

Summary            : IT instruction doesn't accept lowercase conditions

Fixed in           : 5.2.0B1
Severity           : S3 - Minor
Affected Component : Assembler

Release Notes:
  The IT instruction should accept both uppercase and lowercase condition
  codes, but it rejects lowercase condition codes.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.10, 5.1.0B1 -
  5.1.8, 5.0.4.102

Workaround:
  Use uppercase condition codes

-------------------------------------------------------------------------------
FIXED SDSCM00049165
-------------------------------------------------------------------------------

Summary            : Crash on object file with very long names, such as
                     mangled C++ templates

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : Disassembler (dis)

Release Notes:
  The disassembler prints symbols as labels when disassembling an object
  file. If any of those labels was longer than 256 characters, the
  label would overflow a buffer and cause memory corruption, possibly
  crashing the disassembler. Labels of that length are fairly common in
  C++ programs using templates.
  
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121,
  4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 -
  5.0.7, 5.1.0B1 - 5.1.3

Workaround:
  Use "armstrip" or "armstrip -p" to remove symbols from the file.

-------------------------------------------------------------------------------
FIXED SDSCM00049206
-------------------------------------------------------------------------------

Summary            : #pragma CLINK does not work on initialized data

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

Release Notes:
  The CLINK pragma now works as expected for initialized data.
  
  Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.7, 5.1.0B1 - 5.1.3

Workaround:
  Only uninitialized data can be marked CLINK. To make data CLINK, make it
  unitialized and do the initialization at startup.

-------------------------------------------------------------------------------
FIXED SDSCM00049229
-------------------------------------------------------------------------------

Summary            : Symbols are missing in .debug_pubnames part of the Dwarf
                     information

Fixed in           : 5.2.0B1
Severity           : S1 - Critical / PS
Affected Component : C/C++ Compiler (cl)

Release Notes:
  This bug happens all the time. It causes the missing of .debug_pubnames
  section. If the users rely on the .debug_pubnames to search the global
  variable or function's debug information entry, he will see this bug and
  will have no .debug_pubnames sections.
  
  This bug should only affect debug capability. Not the execution results.

Workaround:
  There is no work around for this bug.

-------------------------------------------------------------------------------
FIXED SDSCM00049271
-------------------------------------------------------------------------------

Summary            : INTERNAL ERROR results when building code that uses
                     features from C++ testing framework

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : C/C++ Compiler (cl)
Duplicate Defects  : SDSCM00050480

Release Notes:
  The compiler correctly handles const variables that are referenced in a
  program using templates.

Workaround:
  declare VAR as "extern const int VAR = 1;"

-------------------------------------------------------------------------------
FIXED SDSCM00049326
-------------------------------------------------------------------------------

Summary            : RTTI is enabled by default with no way to disable it. 
                     For C++ code, this can cause data size to double.

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

Release Notes:
  For COFF executables, when --rtti is not used, the compiler will suppress RTTI
  information, leaving the executable file a bit smaller.

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00049328
-------------------------------------------------------------------------------

Summary            : Linker fails to link object that relies on section level
                     attributes for compatibility

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : Linker

Release Notes:
  The symptom of this bug is interlinking with a file generated by the ARM Ltd.
  (Keil) compiler. The error message is:
  error: file "cpu.o" does not preserve 8-byte alignment of 8-byte data, but
  other input files require this; incompatible files
  
  The ARM Ltd. compiler is using section level build attributes in the
  file. Section level and symbol level attributes are deprecated according
  to ARM document IHI 0045D from late 2012. The TI compiler will now issue
  a warning if these deprecated attributes are found, and bypass file
  compatibility checking. The link will continue. The user must insure
  that the files are compatible.

Workaround:
  If you believe that the error message is erroneous, it can be suppressed using
  --diag_suppress=16012.

-------------------------------------------------------------------------------
FIXED SDSCM00049355
-------------------------------------------------------------------------------

Summary            : The linker generates a relocation overflow for 
                     R_ARM_THM_ALU_PREL_11_0 when linking with IAR object
                     files.

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : ELF Linker

Release Notes:
  The current TI ARM tools do not use this relocation type. This bug
  occurs when interlinking with other ARM compilers; the IAR tools have
  been specifically found to use this relocation type. The error in the TI
  tools while handling this relocation type is now fixed.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0 - 4.9.9, 5.0.0B1 - 5.0.8,
  5.1.0B1 - 5.1.3

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00049407
-------------------------------------------------------------------------------

Summary            : FAILURE in optimizer on local static variables with
                     --opt_level=4

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : Optimizer
Duplicate Defects  : SDSCM00049409

Release Notes:
  In rare cases, the optimizer may emit a spurious diagnostic message
  which says "FAILURE in mark_use_of_function_local_static." This
  message includes some symbol names, the first of which will be
  partially garbled. This message does not affect the generated code,
  so it may be ignored.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.200 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.8

Workaround:
  Ignore the message "FAILURE in mark_use_of_function_local_static."

-------------------------------------------------------------------------------
FIXED SDSCM00049420
-------------------------------------------------------------------------------

Summary            : Trampolines generated for symbols defined in the linker
                     command file cause a warning and are incorrect

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

Release Notes:
  When a called function beyond the reach of the call instruction, the
  linker uses trampolines to bounce control flow to the called function.
  In ELF, if the called function is an absolute symbol defined in the
  linker command file, the linker would create a trampoline that
  mistakenly bounced control flow to address 0 rather than the proper
  address of the called function.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.8,
  5.1.0B1 - 5.1.3

Workaround:
  Disable trampolines with --trampolines=off or adjust the linker command
  file so that all calls to the function defined with an absolute symbol
  are in-range of the call instruction.

-------------------------------------------------------------------------------
FIXED SDSCM00049421
-------------------------------------------------------------------------------

Summary            : Auto-generated stress test terminate abnormally in
                     optimizer

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

Release Notes:
  This test is a very large sequence of recurrent assignments. The
  compiler combines all of them into one very large statement, and crashes
  or aborts depending on the release and platform.
  
  The reported crash with release C6000 5.1.0 is a stack overflow that happens
  only on Windows. It is probably due to an inefficiency in the Windows
  C++ compiler that was used to build the release, but we can't reproduce
  the problem when we use our current Windows compiler. (C6000 5.1.0 was built
  in 2004.)
  
  The aborts seen in releases C6000 6.1.x through 7.x are due to an overly
  conservative sanity check, triggered by the very large statement.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121,
  4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 -
  5.0.8, 5.1.0B1 - 5.1.5

Workaround:
  Compile at -o0; since the test case involves no loops or control flow,
  that's no less efficient than higher optimisation levels. Or reduce the
  size of the test case, as mentioned in the original report. Or use two
  or more accumulators, combined at the end, instead of one single
  accumulator; that reduces the maximum statement size.

-------------------------------------------------------------------------------
FIXED SDSCM00049443
-------------------------------------------------------------------------------

Summary            : Use of .align directive with large value (>8K) may cause
                     internal assembler error

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

Release Notes:
  This bug will occur when the assembler must generate 64K or more bits of
  fill to achieve the requested alignment for a symbol. One workaround is
  to place the symbol in a separate section. The alignment is then handled
  at link time by placing the section at a properly aligned location.
  
  Defect occurs in TMS470 Compiler versions: 5.1.0B1 - 5.1.4

Workaround:
  Place the symbol into a separate section. The alignment will apply to
  the section; the linker will place the section at the requested
  alignment. For example, the .align for func1 below
  may cause the bug, but the .align for func2 will work as expected.
  
      .text
      ...
      .align 32768 ; May trigger the bug
      func1:
      ...
  
      .sect ".text:func2"
      .align 32768 ; applied to section; assembler bug will not occur
      func2:
      ...
      .text ; switch back to .text section

-------------------------------------------------------------------------------
FIXED SDSCM00049448
-------------------------------------------------------------------------------

Summary            : Erroneous warning about DW_CFA_def_cfa_sf being DWARF 3
                     specific

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : ELF Linker

Release Notes:
  The linker is incorrectly identifying the CIE version as 2 when it is
  really 3. The linker will now correctly identify the CIE version number.
  
  Defect occurs in TMS470 Compiler versions: 4.6.0B1 - 4.6.6, 4.9.0B1 - 4.9.9,
  5.0.0B1 - 5.0.8, 5.1.0B1 - 5.1.3

Workaround:
  It should be safe to ignore the warning

-------------------------------------------------------------------------------
FIXED SDSCM00049603
-------------------------------------------------------------------------------

Summary            : C Initialization records are created for NOLOAD sections

Fixed in           : 5.2.0B1
Severity           : S3 - Minor
Affected Component : ELF Linker

Release Notes:
  A NOLOAD output section is not allocated in the executable file created
  by the linker. If RAM model is used as the initialization method, the section
  will not be initialized by the loader since it is not allocated in memory. If
  ROM model is used it will be initialized because the linker creates
  initialization records in the .cinit section even if the section is marked
  NOLOAD This is a bug.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121,
  4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 -
  5.0.8, 5.1.4 - 5.1.5

Workaround:
  Specify the type as NOINIT in addition to NOLOAD

-------------------------------------------------------------------------------
FIXED SDSCM00049859
-------------------------------------------------------------------------------

Summary            : Compiler fails with INTERNAL ERROR message

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

Release Notes:
  The attached test case fails with this message ...
  
  INTERNAL ERROR: armacpia experienced a segmentation fault
  while processing function startExciteSequence file file.c line 441
  
  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

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00049921
-------------------------------------------------------------------------------

Summary            : Compiler generates CBZ to a label that is too far away

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

Release Notes:
  On Cortex devices, the compiler may generate a CBZ instruction with a
  destination branch that is too far away. This bug can only appear
  when --unaligned_access=on, which is the default for Cortex devices.
  
  Defect occurs in TMS470 Compiler versions: 5.1.0B1 - 5.1.5

Workaround:
  Use the option --unaligned_access=off

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

Summary            : Loop with volatile loop control expression removed

Fixed in           : 5.2.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 TMS470 Compiler versions: 2.54.02 - 2.54.209, 2.54.03 -
  2.54.129, 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210,
  4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.9, 5.1.0B1 - 5.1.6

Workaround:
  Declare the loop counter variable as volatile

-------------------------------------------------------------------------------
FIXED SDSCM00050014
-------------------------------------------------------------------------------

Summary            : Missing copyright notice on mklib.c source

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

Release Notes:
  The source code for mklib (mklib.c) is part of the product but lacks a
  proper copyright statement. This file should have the same copyright
  as the other TI-generated source files in the RTS library source code.
  
  Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.8, 5.1.0B1 - 5.1.5

Workaround:
  Not applicable

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

Summary            : SIGSEGV when using pragma on a template function

Fixed in           : 5.2.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 TMS470 Compiler versions: 2.54.02 - 2.54.209, 2.54.03 -
  2.54.129, 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210,
  4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.8, 5.1.0B1 - 5.1.5

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

-------------------------------------------------------------------------------
FIXED SDSCM00050051
-------------------------------------------------------------------------------

Summary            : Table driven exception handling code does not check for
                     malloc returning NULL

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

Release Notes:
  In programs with extremely small .sysmem, one helper function for C++
  exception handling would incorrectly handle a failure to allocate the
  global state for C++ exception handling. Later, if a C++ exception was
  thrown, the program would write to memory locations near 0 and
  potentially crash in a confusing manner. The program ought to have
  aborted when the global state could not be allocated.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.200 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 -
  5.1.8, 5.0.4.100 - 5.0.4.102

Workaround:
  Allocate more space to .sysmem

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

Summary            : MISRA-C rule 19.11 false positive

Fixed in           : 5.2.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 SDSCM00050243
-------------------------------------------------------------------------------

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

Fixed in           : 5.2.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 TMS470 Compiler versions: 2.54.02 - 2.54.209, 2.54.03 -
  2.54.129, 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210,
  4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.9, 5.1.0B1 - 5.1.7, 5.0.4.100 - 5.0.4.102

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

Summary            : TDEH emergency buffer should be allocated on stack

Fixed in           : 5.2.0B1
Severity           : S3 - Minor
Affected Component : Runtime Support Libraries (RTS)

Release Notes:
  The TI RTS has an "emergency buffer" functionality for C++ exception
  handling. The emergency buffer pre-allocates enough space for one
  std::bad_alloc object, so that if an allocation failure occurs in a
  low-memory situation, we can at least handle the bad_alloc exception
  gracefully. However, the C++ exception handling code tries to malloc
  a buffer to hold the register context for phase 1 of the stack
  unwinding pass. This means that in the very situation where we need
  the emergency buffer, we couldn't possibly malloc the register
  context. Thus, despite having been careful to create the emergency
  buffer, it can't work, because we'll invariably run out of memory
  trying to use it.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 -
  5.1.8, 5.0.4.102

Workaround:
  Allocate more space to .sysmem

-------------------------------------------------------------------------------
FIXED SDSCM00050520
-------------------------------------------------------------------------------

Summary            : strip crashes on files with more than 64k sections

Fixed in           : 5.2.0B1
Severity           : S2 - Major
Affected Component : Strip Utility

Release Notes:
  The strip utility will abnormally terminate if its input is an ELF
  file with more than 64k sections (actually exactly 0xff00), and its
  output would be less than 64k sections.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.9, 5.1.0B1 -
  5.1.6, 5.0.4.102

Workaround:
  Don't strip the file

-------------------------------------------------------------------------------
FIXED SDSCM00050677
-------------------------------------------------------------------------------

Summary            : Using --opt_level=1 or higher causes compiler to fail
                     with INTERNAL ERROR: >>>Register allocation failed

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

Release Notes:
  Floating point registers are causing INTERNAL ERROR: register
  allocation failure.

Workaround:
  Use _itof and _ftoi intrinsics

-------------------------------------------------------------------------------
FIXED SDSCM00050689
-------------------------------------------------------------------------------

Summary            : Non-status setting MOV Rd, Rs should be allowed for
                     Cortex-M0

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

Release Notes:
  In UAL mode for ARM v6 and above, the syntax "MOV Rd, Rs" should be
  allowed for any registers, and should not set status. However, the
  assembler rejected it with an error.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.10, 5.1.0B1 -
  5.1.7, 5.0.4.102

Workaround:
  Use the CPY Rd, Rs syntax

-------------------------------------------------------------------------------
FIXED SDSCM00050713
-------------------------------------------------------------------------------

Summary            : Optimization level -o3 inlines weak function body

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

Release Notes:
  A function declared as weak may be inlined, which is incorrect because
  the linker may override the weak definition later.

Workaround:
  Use the FUNC_CANNOT_INLINE pragma to directly inhibit inlining.

-------------------------------------------------------------------------------
FIXED SDSCM00050721
-------------------------------------------------------------------------------

Summary            : Compiler truncates 64-bit case labels

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

Release Notes:
  In some cases, the compiler optimizes switch case label comparisons by
  computing the difference between two adjacent case labels. The bug is
  that the compiler may truncate this difference to a 32-bit value.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.10, 5.1.0B1 -
  5.1.7, 5.0.4.102

Workaround:
  Do not use a switch involving case labels with value larger than 32 bits;
  use nested if/else statements instead.

-------------------------------------------------------------------------------
FIXED SDSCM00050732
-------------------------------------------------------------------------------

Summary            : unsigned comparison to zero evaluated incorrectly

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

Release Notes:
  The compiler can generate incorrect code for an unsigned comparison to a
  register which is zero, where the register is negated before
  comparison.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.10, 5.1.0B1 -
  5.1.7, 5.0.4.102

Workaround:
  No practical workaround

-------------------------------------------------------------------------------
FIXED SDSCM00050742
-------------------------------------------------------------------------------

Summary            : Should allow "ADD R0, R1" for v6m0

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

Release Notes:
  In UAL notation, the instruction "ADD Rn, Rm" does not set the status.
  Thumb 2 adds a 16-bit encoding for this instruction when where Rn and
  Rm are low registers. The assembler allowed this instruction for v7
  or above. However, while Cortex-M0 is considered v6, it is actually a
  Thumb 2, so the test should be against T2, not v7.
  
  Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.10, 5.1.0B1 -
  5.1.7, 5.0.4.102
  
  
  TMS470 Compiler versions: 5.0.0B1 - 5.0.10, 5.1.0B1 - 5.1.8, 5.0.4.102

Workaround:
  No practical workaround

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

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

Fixed in           : 5.2.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 SDSCM00050825
-------------------------------------------------------------------------------

Summary            : Should not require explicit S bit on CMN, TST
                     instructions in UAL mode

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

Release Notes:
  Although CMP, CMN, and TST do set the status bits, the UAL syntax does
  not require an explicit S bit suffix when these instructions are used.
  The TI compiler should accept them without an S suffix, but it does not
  accept CMN or TST without the S suffix.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.10, 5.1.0B1 -
  5.1.7, 5.0.4.102

Workaround:
  Add the S suffix when using TI compilers in UAL mode

-------------------------------------------------------------------------------
FIXED SDSCM00050860
-------------------------------------------------------------------------------

Summary            : In pre-UAL syntax Cortex, "ADD R2, R0" should set sign

Fixed in           : 5.2.0B1
Severity           : S3 - Minor
Affected Component : Assembler

Release Notes:
  In pre-UAL syntax Cortex, "ADD R2, R0" should set sign
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 -
  4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.10, 5.1.0B1 -
  5.1.8, 5.0.4.102

Workaround:
  No practical workaround


===============================================================================
5. Current Known Issues
===============================================================================

The following 49 known issues exist for TMS470 Code Generation Tools release
5.2.2 as of January 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 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 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 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 SDSCM00033221
-------------------------------------------------------------------------------

Summary            : The linker allows linking of VFP ARM object files with
                     non-VFP TI object files, but does not allow linking of
                     two VFP files
Affected Component : C/C++ Compiler (cl)

Description:
  The linker does not generate an error if the user attempts to link together an
  object file compiled with the ARM tools with VFP support and an object file
  compiled with TI tools without VFP support.
  
  Also, the linker does generate an error message when trying to link together
  two VFP files, one compiled with ARM tools and the other with TI tools.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00036770
-------------------------------------------------------------------------------

Summary            : LDREXD and STREXD instructions erroneously generate
                     errors on Cortex A8 and R4
Affected Component : Assembler

Description:
  LDREXD and STREXD are valid instructions on Cortex R4 and A8 architectures but
  the assembler generates errors. The first error states that [Rn] must be a
  register indirect and the second complains of unexpected trailing operands.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00036773
-------------------------------------------------------------------------------

Summary            : LDM/STM -DA/FA/IB/ED viariant instructions erroneously
                     accepted by assembler for Cortex-M3
Affected Component : Assembler

Description:
  LDM and STM instructions ending with DA, FA, IB and ED are not available in
  the Thumb instruction set, but the assembler accepts these for Cortex-M3 and
  converts them to LDM and STM instructions ending with IA.W.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00036874
-------------------------------------------------------------------------------

Summary            : Section relative ELF symbol values in partially linking
                     object files should hold the section offset for the
                     symbol
Affected Component : ELF Linker

Description:
  The symbol value in an ELF relocatable file should be the offset from the
  beginning of the section. Typically the sections all start at address 0, so
  the value corresponds to its address in the file. In a partially linking
  object file, the sections will start at different addresses. The symbol values
  contain the absolute address instead of the offset.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00037008
-------------------------------------------------------------------------------

Summary            : Linker outputting wrong build attribute name for EABI
                     TAG_VFP_arch on ARM targets
Affected Component : ELF Linker

Description:
  For TMS470, linker outputs EABI build attribute TAG_VFP_arch name as "Producer
  Minor Version + 1" instead of the correct name for the specific tag value. The
  TI build attribute TAG_VFP_arch name is printed correctly. The names are
  entered correctly for the EABI VFP_arch tag values but are not being accessed.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00037086
-------------------------------------------------------------------------------

Summary            : ARM assembler allows incorrect VFP registers for some
                     instructions on D16 VFP architectures
Affected Component : Assembler

Description:
  ARM assembler allows the use of VFP registers D16-D31 on D16 VFP targets for
  the following VFP instructions: single and multiple loads and stores, pop,
  push, and register transfers between VFP and core registers.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00037227
-------------------------------------------------------------------------------

Summary            : ARM disassembler error for VMRS instruction
Affected Component : Disassembler (dis)

Description:
  The ARM disassembler errorneously disassembles "VMRS APSR_[bits], FPSCR" as
  "VMSR PC, FPSCR". The instruction is formatted as "FMSTAT" in the code
  generator in vfp.md (vfp_transfer_status_to_cpsr).

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00037308
-------------------------------------------------------------------------------

Summary            : Assembler does not encode the proper offset for a VLDR
                     immediate instruction in thumb 2 mode
Affected Component : Assembler

Description:
  In thumb 2 mode, the value of the PC register at a given instruction is PC+4
  (in ARM it is PC+8). When encoding the VLDR instruction the assembler always
  encodes the instruction as if the PC is PC+8. This will cause the VLDR
  instruction to never work correctly in thumb 2 mode.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00038278
-------------------------------------------------------------------------------

Summary            : ARM floating point conversion routines do not support
                     NaN
Affected Component : Runtime Support Libraries (RTS)

Description:
  The ARM assembly routines that handle converting floating point types do not
  handle NaN correctly. In these routines NaN is considered to be infinity.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00038327
-------------------------------------------------------------------------------

Summary            : ARM RTS libraries expose enumerations across ABI
                     boundaries, but are marked as having no visible
                     enumerations
Affected Component : Runtime Support Libraries (RTS)

Description:
  The ARM RTS libraries are marked as having no visible enumerations. This is
  true for the C library routines, but not the C++. Some C++ header files
  include inline functions that manipulate enumeration values. Possible
  solutions:
  
  1. Quit marking libraries as having no visible enums. This is bad because then
     we will have to provide libraries with both enum types.
  2. Get rid of the enumerations.
  3. Force enumerations exposed in header files to be either packed or int.
     Packed can be done using the packed gcc attribute. The trouble is that for
     ARM, gcc attributes are not available without the --gcc switch. I believe
     C6x exposes attributes by default, so we can probably make the switch for
     ARM (and maybe all targets). Forcing enums to be int can be done by
     including a dummy enumerator in every enumeration that is INT_MAX.

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

Summary            : Assembler does not accept the SP operand of the SRSDB
                     instruction
Affected Component : Assembler

Description:
  The assembler accepts SRSDB #<mode>, but the reference manual specifies that
  the instruction should have an SP! operand.

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

Summary            : ARM assembler does not issue a warning for PC-relative
                     loads when --embedded_constants=off
Affected Component : Assembler

Description:
  When the --embedded_constants=of option is used, the assembler is supposed to
  issue an error message if it detects any PC-relative loads. It does this for
  LDR instructions that are 32-bits long, but not for the 16-bit versions.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00039636
-------------------------------------------------------------------------------

Summary            : When creating a partial linked ELF object file, the
                     linker uses virtual addresses instead of relative
                     addresses.
Affected Component : Linker

Description:
  In ELF, relocatable object files should always using section relative values
  for relocation offsets and symbols values. When creating a partially linked
  object file the linker uses virtual addresses for these values.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00040522
-------------------------------------------------------------------------------

Summary            : _ssatl intrinsic allows 3rd argument to be 0 resulting
                     in an assembler error.
Affected Component : Parser

Description:
  The SSAT instruction does not accept a 0 for the immediate argument. We should
  ensure in the parser that 0 is not allowed.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00040523
-------------------------------------------------------------------------------

Summary            : The _ssat16 intrinsic allows literals in the range of
                     0-31, but the SSAT16 instruction only accepts values
                     from 1-16
Affected Component : Parser

Description:
  The parser should catch this so the assembler doesn't generate an error.

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

Summary            : Internal error when compiling code with WEAK functions;
                     linker crash
Affected Component : C/C++ Compiler (cl)

Description:
  /*
  Command line:
  cl470 --abi=eabi weak2.c -z -l
  c:\Programme\TexasInstruments\ccsv4\tools\compiler\tms470\lib\libc.a
  
     Resulting output:
     <Linking>
     warning: output section ".data" refers to load symbol "weakFunc" and hence
     cannot be compressed; compression "rle" is ignored
     warning: output section ".data" refers to load symbol "weakFunc" and hence
     cannot be compressed; compression "rle" is ignored
     table.c:3601:internal fatal error #10225: (.cinit..data.load)
  
       This application has requested the Runtime to terminate it in an unusual
       way.
       Please contact the application's support team for more information.
  
       INTERNAL ERROR: lnk470 aborted
  
  
       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
  
     Toolchain: TMS470 4.6.4 or 4.6.6 on 32-bit WinXP SP3.
     */
  
  #pragma WEAK(weakFunc);
  extern void weakFunc();
  
  void (*ptr)() = weakFunc;
  
  int main()
  {
     if (ptr)
        ptr();
  }

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

Summary            : -pdse=195 causes an error under EABI if any standard
                     header file is included
Affected Component : Runtime Support Libraries (RTS)

Description:
  This is the same bug as CQ19871. The problem appears to be that
  _AEABI_PORTABILITY_CHECK is defined in terms of _AEABI_PORTABILITY_LEVEL != 0
  where _AEABI_PORTABILITY_LEVEL is not defined. This same idiom is used in many
  header files.

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

Summary            : float library functions misbehave with -me
                     --float_support=fpalib
Affected Component : Runtime Support Libraries (RTS)

Description:
  Fails with optmization, passes with --no_high_level_opt, but the optimizer
  seems to be doing the right thing.
  
  Something is swapping the words in the double. If the words for each float
  constant in the assembly code are reversed, the test case works. I don't know
  whether the compiler is creating the float constants with the wrong endianness
  or the library is handling it with the wrong endianness.
  
  See also the closely related SDSCM00044038

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00044038
-------------------------------------------------------------------------------

Summary            : float library functions misbehave with --abi=eabi -mv5e
                     -me --float_support=fpalib
Affected Component : Runtime Support Libraries (RTS)

Description:
  Looking at the assembly code test_number gets converted to a double like I
  would expect but the comparison fails.
  
  See also the closely related SDSCM00044035

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

Summary            : MISRA 12.8 and MISRA 10.5 false positives
Affected Component : Parser

Description:
  I was wondering if the compiler's MISRA checking is reporting false positives.
  I have the following code
  
  #define DEF_X (0x00000001UL)
  #define DEF_Y (4U)
  
  static void foo(void)
  
  {
  
      uint32 nReadData;
  
      nReadData = DEF_X << DEF_Y;
  
  }
  
  This gives me a MISRA error...
  
  #1397-D (MISRA-C:2004 10.5/R) If the bitwise operators ~ and << are applied to
  #an operand of underlying type unsigned char or unsigned short, the result
  #shall be immediately cast to the underlying type of the operand.
  
  But the underlying type is a "UL" or 32bit unsigned integer.
  
  If I try to fix the error using the code...
  
   nReadData = (uint32)DEF_X << DEF_Y;
  
  This gives me a MISRA error...
  
  #1407-D (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
  
  But the right hand operator has a value of 4 and the left hand operator
  is 32 bits.
  
  The only way I can solve the problem is by assigning the #define values to
  temporary variables and then doing the shift operation with these.
  
  With this in mind I think the misra checking is not handling the #define
  values correctly.. Am I correct in this assumption?

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00046352
-------------------------------------------------------------------------------

Summary            : Disassembler does not emit certain instructions in UAL
                     form by default
Affected Component : Disassembler (dis)

Description:
  See the test case for SDSCM00046351.
  For 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:
  UAL syntax:
  LSLSEQ R2, R2, #2
  LSLSNE R2, R2, #2
  disassembler output: (7A8)
  MOVEQS R2, R2, LSL #2
  MOVNES R2, R2, LSL #2
  I've no idea whether UAL expects the LSL or MOV syntax. rv40fromelf -c ouputs
  the LSL form, so I assume that's the UAL form.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00046409
-------------------------------------------------------------------------------

Summary            : __ldrex pointer parameter should be "volatile void*"
Affected Component : C/C++ Compiler (cl)

Description:
  (This question was originally posted in the Stellaris area but Dave pointed
  out that it really belongs here)
  
  __ldrex and __strex intrinsics don't qualify parameter with volatile.
  
  According to ARM, the pointer parameter should be "volatile void*".
  http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491c/CJA-
  FAFAF.html
  
  I have a variable which many source tasks race to change from zero to non-
  zero; this should use LL-SC. But only one sink task can change it when
  already non-zero. The sink task therefore doesn't need LL-SC, merely a
  volatile read and volatile write. However, the compiler won't let me mark the
  variable as volatile.
  
  These intrinsics should accept a pointer to volatile, because they access the
  location with volatile semantics, and the volatile qualifier can be implicitly
  added but not removed.
  
  
  volatile uint8_t active;
  
  do {
    if (__ldrexb(&active)) return;
  } while (__strexb(5, &active));
  
  
  Is there some reason that these instructions wouldn't behave as expected with
  volatile variables?

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00047077
-------------------------------------------------------------------------------

Summary            : Incorrectly reduced double constant to float when
                     ultimate destination is short
Affected Component : C/C++ Compiler (cl)

Description:
  The expression ushort = 0.04f * 1000.0 gets a different value than ulong =
  0.04f * 1000.0, even in strict mode.
  
  To understand what you're seeing, you need to be aware of these facts:
  
      The value 0.04 is not exactly representable in IEEE-754 binary floating-
      point format. The value used in the compiler is approximately
      0.039999999105930328369140625 (exactly 0x1.47ae14p-5, in C99 hex format).
      1000.0 is a double-precision float constant because you didn't use the 'f'
      suffix. 1000.0f is a single-precision float constant.
      When you perform arithmetic on floating-point types, rounding occurs
      When you perform arithmetic on mixed types, the compiler must promote them
      to a common type, usually the larger of the two.
  
  Now, what's going on is that you are multiplying the single-precision variable
  fTest by a double-precision value 1000.0. This requires the compiler to
  promote the value in fTest to a double, which means adding a bunch of zeros on
  the end. The compiler then rounds the double-precision result, which has a lot
  of zeros at the end, so it doesn't round up. Then the value gets truncated to
  an integer type for assignment to an integer.
  
  The parser assumes that (because the ultimate destination has only 16 bits)
  that it is safe to convert 1000.0 to 1000.0f; the problem is that this changes
  the result. This is safe if the ultimate destination is float, because double-
  >float conversion rounds, but double->integer truncates.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00047902
-------------------------------------------------------------------------------

Summary            : Predefined macro __TI_FPv4SPD16_SUPPORT__ should be
                     __TI_FPV4SPD16_SUPPORT__
Affected Component : Parser

Description:
  The convention for predefined macros representing subtargets and features is
  to capitalize every letter. The predefined macro __TI_FPv4SPD16_SUPPORT__
  should thus be __TI_FPV4SPD16_SUPPORT__. Recommend adding the latter, and
  keeping but deprecating the former

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00048267
-------------------------------------------------------------------------------

Summary            : Warning generated when using __curpc intrinsic on Thumb
                     2
Affected Component : Code Generator

Description:
  When using the __curpc intrinsic in Thumb 2 mode, the compiler generates code
  for which the assembler gives a warning. This should not affect the execution
  of the __curpc instruction, but could indicate incorrect execution of
  surrounding instructions.
  "file.asm", WARNING! at line 54: [W0004] Invalid instruction modifier(s)
  ignored
  MOVR A1, PC; MOVE REG-TO-REG ; [DPU_4_PIPE0] |2|

-------------------------------------------------------------------------------
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;  
  } 
  
  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 SDSCM00049911
-------------------------------------------------------------------------------

Summary            : __aeabi_dcmpun returns 1 for Inf and -Inf
Affected Component : Runtime Support Libraries (RTS)

Description:
  ARM EABI function __aeabi_dcmpun is a binary function which returns 1 if
  either operand is NaN, and 0 otherwise. However, when either operand is +-Inf,
  it returns 1. __aeabi_dcmpun does not have this bug.

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

Summary            : The .label assembler directive should not be accepted
                     when assembling for ELF.
Affected Component : Assembler

Description:
  The .label directive creates a symbol that will have the value of the load
  address of a section. This cannot be done in ELF so the directive should issue
  an error. It's usefulness has been subsumed by other mechanisms (symbols
  defined in the linker command file and copy tables).

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00050861
-------------------------------------------------------------------------------

Summary            : Should accept 2-operand add in ARM mode
Affected Component : Assembler

Description:
  TI's assembler does not accept the 2-operand syntax for specifying the 3-
  operand ARM ADD instruction. Although the UAL doesn't seem to require the tool
  to allow this syntax, RVCT accepts this form, so we should, too.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00051292
-------------------------------------------------------------------------------

Summary            : __rev should accept and return an unsigned int instead
                     of a signed int.
Affected Component : C/C++ Compiler (cl)

Description:
  Since __rev is performing bit manipulations, I think it makes sense to have it
  work on unsigned types instead of signed ones. With the return value being
  signed, users can get unexpected results when casting to an unsigned long long
  types since sign extension will be performed.

