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

-------------------------------------------------------------------------------
Table of Contents
-------------------------------------------------------------------------------
1. Defects fixed in TMS470 Code Generation Tools release 5.1.10
2. Defects fixed in TMS470 Code Generation Tools release 5.1.9
3. Defects fixed in TMS470 Code Generation Tools release 5.1.8
4. Defects fixed in TMS470 Code Generation Tools release 5.1.7
5. Defects fixed in TMS470 Code Generation Tools release 5.1.6
6. Defects fixed in TMS470 Code Generation Tools release 5.1.5
7. Defects fixed in TMS470 Code Generation Tools release 5.1.4
8. Defects fixed in TMS470 Code Generation Tools release 5.1.3
9. Defects fixed in TMS470 Code Generation Tools release 5.1.2
10. Defects fixed in TMS470 Code Generation Tools release 5.1.1
11. Defects fixed in TMS470 Code Generation Tools release 5.1.0
12. Defects fixed in TMS470 Code Generation Tools release 5.1.0B1
13. Current Known Issues


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

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

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

Summary            : Bound function has incorrect address in DWARF debug info

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

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


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

The following 9 defects were fixed in TMS470 Code Generation Tools release
5.1.9, released November 2014.

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

Summary            : IT instruction doesn't accept lowercase conditions

Fixed in           : 5.1.9
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 SDSCM00050051
-------------------------------------------------------------------------------

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

Fixed in           : 5.1.9
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 SDSCM00050505
-------------------------------------------------------------------------------

Summary            : TDEH emergency buffer should be allocated on stack

Fixed in           : 5.1.9
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 SDSCM00050742
-------------------------------------------------------------------------------

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

Fixed in           : 5.1.9
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 SDSCM00050860
-------------------------------------------------------------------------------

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

Fixed in           : 5.1.9
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

-------------------------------------------------------------------------------
FIXED SDSCM00050973
-------------------------------------------------------------------------------

Summary            : The function __aeabi_uidiv is missing in the RTS

Fixed in           : 5.1.9
Severity           : S2 - Major
Affected Component : Runtime Support Libraries (RTS)
Duplicate Defects  : SDSCM00045035

Release Notes:
  The function __aeabi_uidiv is required by ARM EABI, but missing from TI's
  library.
  
  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:
  Link with another vendor's linker, or add a function named __aeabi_uidiv
  which takes two unsigned int arguments and calls __aeabi_uidivmod

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

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

Fixed in           : 5.1.9
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.1.9
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 SDSCM00051155
-------------------------------------------------------------------------------

Summary            : Compiler does not define __TI_GNU_ATTRIBUTE_SUPPORT__ as
                     the documentation describes

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

Release Notes:
  There is no method by which a customer can implement a compile time check on
  whether GCC extensions are supported.

Workaround:
  None.


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

The following 10 defects were fixed in TMS470 Code Generation Tools release
5.1.8, released September 2014.

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

Summary            : Assembler mishandles certain combinations of S and
                     condition codes

Fixed in           : 5.1.8
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 SDSCM00048891
-------------------------------------------------------------------------------

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

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

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

Fixed in           : 5.1.8
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 SDSCM00050512
-------------------------------------------------------------------------------

Summary            : Compiler does not handle control-C signal as expected

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

Release Notes:
  Added signal catchers for SIGINT and SIGBREAK on non-Unix hosts, so the tool
  exits cleanly instead of falling into the segfault report mechanism.

Workaround:
  Later compiler releases (7.6.x and above) do not suffer from this problem.

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

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

Fixed in           : 5.1.8
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.1.8
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 SDSCM00050721
-------------------------------------------------------------------------------

Summary            : Compiler truncates 64-bit case labels

Fixed in           : 5.1.8
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.1.8
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 SDSCM00050763
-------------------------------------------------------------------------------

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

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


===============================================================================
4. Defects fixed in TMS470 Code Generation Tools release 5.1.7
===============================================================================

The following 7 defects were fixed in TMS470 Code Generation Tools release
5.1.7, released July 2014.

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

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

Fixed in           : 5.1.7
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 SDSCM00049997
-------------------------------------------------------------------------------

Summary            : Loop with volatile loop control expression removed

Fixed in           : 5.1.7
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 SDSCM00050202
-------------------------------------------------------------------------------

Summary            : MISRA-C rule 19.11 false positive

Fixed in           : 5.1.7
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 SDSCM00050350
-------------------------------------------------------------------------------

Summary            : ARM _enable_interrupts() _disable_interrupts() had wrong
                     implementation for 6M0

Fixed in           : 5.1.7
Severity           : S3 - Minor
Affected Component : Code Generator

Release Notes:
  For Cortex-M0, intrinsics _enable_interrupts(), _disable_interrupts() and
  _restore_interrupts() incorrectly used the FAULTMASK instead of PRIMASK.

Workaround:
  Use inline assembly with "CPSID i" or "CPSIE i" or "MSR PRIMASK, setting"

-------------------------------------------------------------------------------
FIXED SDSCM00050351
-------------------------------------------------------------------------------

Summary            : --symdebug:none and --symdebug:dwarf_version conflict
                     when using -o4

Fixed in           : 5.1.7
Severity           : S3 - Minor
Affected Component : ILinker (File Merge)
Duplicate Defects  : SDSCM00048790

Release Notes:
  The --symdebug:none and --symdebug:dwarf_version conflict when combined during
  LTO. The --symdebug:none and --symdebug:dwarf options are fine together so --
  symdebug:dwarf_version should not cause a problem.

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00050352
-------------------------------------------------------------------------------

Summary            : Combining -pm and -o4 on the command line causes an
                     error during -o4.

Fixed in           : 5.1.7
Severity           : S3 - Minor
Affected Component : ILinker (File Merge)

Release Notes:
  When combining the -pm and -o4 options, an error occurs during the LTO phase.
  These option should be allowed to work together.

Workaround:
  None.

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

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

Fixed in           : 5.1.7
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


===============================================================================
5. Defects fixed in TMS470 Code Generation Tools release 5.1.6
===============================================================================

The following 9 defects were fixed in TMS470 Code Generation Tools release
5.1.6, released May 2014.

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

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

Fixed in           : 5.1.6
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 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.1.6
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 SDSCM00049421
-------------------------------------------------------------------------------

Summary            : Auto-generated stress test terminate abnormally in
                     optimizer

Fixed in           : 5.1.6
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 SDSCM00049603
-------------------------------------------------------------------------------

Summary            : C Initialization records are created for NOLOAD sections

Fixed in           : 5.1.6
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.1.6
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 SDSCM00049897
-------------------------------------------------------------------------------

Summary            : Compiler tools are getting installed into tms470_xxx
                     directory instead of arm_xxx

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

Release Notes:
  Compiler tools are getting installed into tms470_xxx directory instead
  of arm_xxx

Workaround:
  None.

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

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

Fixed in           : 5.1.6
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 SDSCM00050014
-------------------------------------------------------------------------------

Summary            : Missing copyright notice on mklib.c source

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


===============================================================================
6. Defects fixed in TMS470 Code Generation Tools release 5.1.5
===============================================================================

The following 2 defects were fixed in TMS470 Code Generation Tools release
5.1.5, released February 2014.

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

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

Fixed in           : 5.1.5
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 SDSCM00049443
-------------------------------------------------------------------------------

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

Fixed in           : 5.1.5
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


===============================================================================
7. Defects fixed in TMS470 Code Generation Tools release 5.1.4
===============================================================================

The following 8 defects were fixed in TMS470 Code Generation Tools release
5.1.4, released February 2014.

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

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

Fixed in           : 5.1.4
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 SDSCM00047666
-------------------------------------------------------------------------------

Summary            : Definition of SIZE_MAX is wrong

Fixed in           : 5.1.4
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 SDSCM00049165
-------------------------------------------------------------------------------

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

Fixed in           : 5.1.4
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.1.4
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 SDSCM00049271
-------------------------------------------------------------------------------

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

Fixed in           : 5.1.4
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 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.1.4
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 SDSCM00049420
-------------------------------------------------------------------------------

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

Fixed in           : 5.1.4
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 SDSCM00049448
-------------------------------------------------------------------------------

Summary            : Erroneous warning about DW_CFA_def_cfa_sf being DWARF 3
                     specific

Fixed in           : 5.1.4
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


===============================================================================
8. Defects fixed in TMS470 Code Generation Tools release 5.1.3
===============================================================================

The following 13 defects were fixed in TMS470 Code Generation Tools release
5.1.3, released December 2013.

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

Summary            : Inline jump table mistakenly gets .clink attached

Fixed in           : 5.1.3
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 SDSCM00046180
-------------------------------------------------------------------------------

Summary            : MISRA check 14.1 should not treat while(0) as potential
                     infinte loop

Fixed in           : 5.1.3
Severity           : S3 - Minor
Affected Component : Parser

Release Notes:
    Misra rule 14.1 no longer emits a false warning for do{} while(0).
  

Workaround:
  None.

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

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

Fixed in           : 5.1.3
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 SDSCM00048289
-------------------------------------------------------------------------------

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

Fixed in           : 5.1.3
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.1.3
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.1.3
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.1.3
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 SDSCM00048513
-------------------------------------------------------------------------------

Summary            : ARM linker generates an overflow error for R_ARM_THM_PC8
                     relocation

Fixed in           : 5.1.3
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.1.3
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.1.3
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.1.3
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 SDSCM00048936
-------------------------------------------------------------------------------

Summary            : Linker generated ECC is not correct for F035 devices

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


===============================================================================
9. Defects fixed in TMS470 Code Generation Tools release 5.1.2
===============================================================================

The following 8 defects were fixed in TMS470 Code Generation Tools release
5.1.2, released September 2013.

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

Summary            : fgets in _IONBF mode does not respect size limit

Fixed in           : 5.1.2
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.1.2
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 SDSCM00043860
-------------------------------------------------------------------------------

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

Fixed in           : 5.1.2
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 SDSCM00047502
-------------------------------------------------------------------------------

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

Fixed in           : 5.1.2
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 SDSCM00047774
-------------------------------------------------------------------------------

Summary            : In some cases, compiler fails to use unaligned load when
                     reading members of a packed structure

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

Release Notes:
   The compiler issues an unaligned load instruction LDNW when reading a member
   of a structure.

Workaround:
  None.

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

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

Fixed in           : 5.1.2
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 SDSCM00048263
-------------------------------------------------------------------------------

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

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


===============================================================================
10. Defects fixed in TMS470 Code Generation Tools release 5.1.1
===============================================================================

The following 0 defects were fixed in TMS470 Code Generation Tools release
5.1.1, released October 2013.


===============================================================================
11. Defects fixed in TMS470 Code Generation Tools release 5.1.0
===============================================================================

The following 17 defects were fixed in TMS470 Code Generation Tools release
5.1.0, released July 2013.

-------------------------------------------------------------------------------
FIXED SDSCM00041192
-------------------------------------------------------------------------------

Summary            : Compiler misreports Misra warning for violation of Misra
                     9.2

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

Release Notes:
  Compiler misreports Misra 9.2 warning for zero initialization of single
  dimension float arrays, like the one below:
  
  float array[ 10 ] = {0.0f};

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00044738
-------------------------------------------------------------------------------

Summary            : EABI partial linking omits referenced library functions
                     which refer to unresolved symbols

Fixed in           : 5.1.0
Severity           : S2 - Major
Affected Component : Linker

Release Notes:
  The bug could happen when partial link is used. Also one or more files
  partially linked are compailed with optimization. The optimizer
  recognized some function as alias function. The paritial does not handle
  alias function correctly.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.8, 5.1.0B1

Workaround:
  There is no work around for this bug.

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

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

Fixed in           : 5.1.0
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.1.0
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.1.0
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 SDSCM00046084
-------------------------------------------------------------------------------

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

Fixed in           : 5.1.0
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 SDSCM00046175
-------------------------------------------------------------------------------

Summary            : INTERNAL ERROR: cg6x experienced a segmentation fault
                     while processing function

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

Release Notes:
  This bug could only happen in C++ code with exception turned ON. Another
  added condition is that in this C++ code, there are excpetions thrown
  either in destructor or throw expression. When this bug happens, you will
  see an error emitted from the compiler.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.7, 5.1.0B1

Workaround:
  There is no work around for this bug.

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

Summary            : ELF section header table not guaranteed to be aligned

Fixed in           : 5.1.0
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.1.0
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 SDSCM00046346
-------------------------------------------------------------------------------

Summary            : Linker takes too long to link after upgrade to 7.3.X

Fixed in           : 5.1.0
Severity           : S2 - Major
Classification     : Performance
Affected Component : ELF Linker

Release Notes:
  Long link times can be caused by the linker's type merging pass to reduce
  the debug section size. This problem is usually noticed in large projects
  that contain several hundred files or more. This problem has been addressed
  by an improved type merging algorithm that should reduce link times.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.7, 5.1.0B1

Workaround:
  Use -b can always to wrok around this long type merging problem. But it
  is not needed with this fix.

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

Summary            : Instructions are placed in the wrong order

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


===============================================================================
12. Defects fixed in TMS470 Code Generation Tools release 5.1.0B1
===============================================================================

The following 73 defects were fixed in TMS470 Code Generation Tools release
5.1.0B1, released April 2013.

-------------------------------------------------------------------------------
FIXED SDSCM00008276
-------------------------------------------------------------------------------

Summary            : Linker accepts illegal address ranges and truncates to a
                     valid address

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

Release Notes:
  The linker will now generate an out of range error:
  
  <Linking>
  "./test.cmd", line 4: error: integer constant does not fit within 32-bits:
  "0x123456789"
  error: errors encountered during linking; "test.out" not built

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00037422
-------------------------------------------------------------------------------

Summary            : Incorrect layout in .cdecls struct

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

Release Notes:
  The attached test case defines a structure which contains a union. The last
  field in the structure is assigned the offset 9 by the compiler. The
  assembler, via .cdecls, assigns that same field the offset 10.

Workaround:
  None

-------------------------------------------------------------------------------
FIXED SDSCM00041434
-------------------------------------------------------------------------------

Summary            : Compiler optimizes away certain calls to assert()

Fixed in           : 5.1.0B1
Severity           : S3 - Minor
Affected Component : Absolute Lister

Release Notes:
  Certain assert() statements, most notably "assert(x&1)" and the
  equivalent "assert(x%2==0)", may be removed by the compiler and thus will
  not do the run-time condition check that is desired.
  
  Defect occurs in TMS470 Compiler versions: 2.41.beta - 2.50.beta, 4.4.0B1 -
  4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.116, 4.6.0B1 - 4.6.6, 4.4.15.201
  - 4.4.15.209, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.5, 4.7.1.201 -
  4.7.1.202, 5.0.0B1

Workaround:
  Instead of "assert(p)", use "if (!p) assert(0)", which will still abort
  at the same place under the same conditions, but will have a different
  error message. More elaborately, implement a function equivalent to
  assert() but with a different name, that the compiler will not recognise
  as a system function.

-------------------------------------------------------------------------------
FIXED SDSCM00041971
-------------------------------------------------------------------------------

Summary            : Spurious remark generated from __STDC_VERSION__ ref in
                     stddef.h in C++ mode

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

Release Notes:
  #include <stddef.h>
  
  int main(void)
  {
      return 2;
  }
  
  Then compile with the following flags:
  
  cl6x a.cpp -pdv -pdr
  
  include/stddef.h", line 87: remark #195-D: zero
  used for undefined preprocessing identifier
  (__STDC_VERSION__ >= 199901L || !__TI_STRICT_ANSI_MODE__)
  
  This happens because __STDC_VERSION__ is not defined in C++ mode

Workaround:
  Use the -pds=195 switch to avoid the remark.

-------------------------------------------------------------------------------
FIXED SDSCM00042194
-------------------------------------------------------------------------------

Summary            : Partial link drops weak function symbol

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

Release Notes:
   The linker now copies the weak symbol into the output file

Workaround:
  None

-------------------------------------------------------------------------------
FIXED SDSCM00042292
-------------------------------------------------------------------------------

Summary            : In EABI mode string literals used in member functions
                     result in static members of the class and not placed in
                     .const:.string

Fixed in           : 5.1.0B1
Severity           : S2 - Major
Classification     : Performance
Affected Component : Parser

Release Notes:
  In EABI mode, the compiler was incorrectly creating static class member char
  arrays for string literals used in member functions instead of putting them in
  .const:.string.

Workaround:
  None

-------------------------------------------------------------------------------
FIXED SDSCM00042332
-------------------------------------------------------------------------------

Summary            : Don't generate typeinfo when not used

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

Release Notes:
  The C++ type info is generated under EABI whenever the virtual function table
  is created as per the IA64 C++ ABI requirement. However, the typeinfo is not
  used if RTTI or C++ exceptions are not used. Hence it is a good candidate to
  place in slow external memory. However, they are presently generated under
  .const section and hence it is difficult to selectively group and place them.
  The proposal is to place the typeinfo under the .const:.typeinfo subsection to
  enable easier placement.
  
  For all targets except C2000's large data mode, typeinfo will now be placed in
  .const:.typeinfo, whereas C2000's large data mode will place it into
  .econst:.typeinfo. This behavior will be default in all future releases, but
  branch patches must provide the --typeinfo_subsections option in the shell to
  activate this placement change. This is because cache behavior could
  potentially be affected by changing the placement of the type information.
  
  To take advantage of this feature, the linker command file must detail the
  placement for the typeinfo subsection, most often times placing it into slow
  external memory to make room for more important data in faster memory.

Workaround:
  None

-------------------------------------------------------------------------------
FIXED SDSCM00042417
-------------------------------------------------------------------------------

Summary            : #pragma WEAK; 'if (f)' gets eliminated even if 'f' is a
                     weak function

Fixed in           : 5.1.0B1
Severity           : S3 - Minor
Affected Component : C/C++ Compiler (cl)
Duplicate Defects  : SDSCM00044527

Release Notes:
  EABI mode allows weak symbol references. If the symbol is weak and
  not defined, its address is zero. The compiler incorrectly assumes
  that the address of a weak symbol is non-zero and simplfies
  comparisons of &symbol to true, but it should not. In other words, if
  the user writes "if (&symbol) symbol_is_defined();", symbol_is_defined
  will be called even if symbol is weak and not defined.
  
  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.118, 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.3

Workaround:
  Create a volatile pointer to hold the weak pointer value before using it
  in any comparisons, including the test in an if statement.

-------------------------------------------------------------------------------
FIXED SDSCM00042444
-------------------------------------------------------------------------------

Summary            : Expression that multiplies two constants incorrectly
                     triggers MISRA rule 10.1 about implicit conversion

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

Release Notes:
  The expression ...
  
    var_int16 = 4 * 256;
  
  contains no implicit conversions. However, MISRA rule 10.1 about no implicit
  conversions is still emitted for that expression.

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00042581
-------------------------------------------------------------------------------

Summary            : Linker fails with internal error: lnk6x failed to
                     allocate memory

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

Release Notes:
  The linker could report an internal error due to a memory allocation
  failure in certain cases. This bug involves the linker options
  --make_static, --localize, or --hide. If any of these options is used in
  a partial link, then the final link may produce the internal error. The
  linker was localizing comdat symbols during the partial link, which is
  incorrect behavior. The result was that the comdat symbols could not be
  resolved in the final link, but this was not detected properly, causing
  the memory allocation failure. One example of a comdat symbol is a
  static data member of a template class. The static data member must be
  resolved to a single instance, so it can not be localized during the
  partial link. This bug fix ensures that --make_static, --localize, and
  --hide do not affect comdat symbols during the partial link, and lists
  these symbols in the mapfile if requested. Also, if a similar symbol
  resolution error is encounted due to some other cause, the linker will
  now detect and report the error instead of encountering a memory
  allocation error later in the linking process.
  
  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.117, 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.2

Workaround:
  This bug can only be triggered if a partial link is performed using the
  --make_static, --localize or --hide option (the memory allocation
  failure will occur during the final link, however). Removing that option
  is one way to avoid this bug. Alternatively, the partial link step may
  be removed from the build process, if possible.

-------------------------------------------------------------------------------
FIXED SDSCM00042595
-------------------------------------------------------------------------------

Summary            : Compiler generates an internal error "no match for
                     COMPARE" for the attached testcase

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

Release Notes:
  Use of unsigned long long types in a comparison causes a codegen crash.

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00042600
-------------------------------------------------------------------------------

Summary            : Ill advised enum scalar usage gets MISRA diagnostic, but
                     similar usage of enum array does not

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

Release Notes:
  The test case given assigned a integer to an enum scalar variable. MISRA
  checking correctly flags this with a diagnostic. The test case goes on to do
  the same thing with an enum array expression. It should get the same MISRA
  diagnostic, but does not. For example:
  
  typedef unsigned int uint16_t;
  
  uint16_t Func(void);
  
  typedef enum Error
  {
      OK,
      NO_DATA,
      BUFFER_FULL
  } Error_t;
  
  const Error_t errors[2] = {OK, OK};
  
  uint16_t Func(void)
  {
      uint16_t myError;
  
      myError = OK; /* correctly flags as error (MISRA 10.1) */
  
      myError = errors[0]; /* does not find error */
  
      return myError;
  }

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00042811
-------------------------------------------------------------------------------

Summary            : printf("%d") with negative values incorrect for
                     printf_support=minimal

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

Release Notes:
  printf("%d") is treated as printf("%u") for --printf_support=minimal,
  which means negative values will be printed incorrectly.
  
  Defect occurs in TMS470 Compiler versions: 5.0.0B1

Workaround:
  Use printf_support=nofloat

-------------------------------------------------------------------------------
FIXED SDSCM00042914
-------------------------------------------------------------------------------

Summary            : Linker segfault using partial link output file of C++
                     source with ELF and exceptions enabled

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

Release Notes:
  The linker fails with a segmentation fault when using a file created by
  partial linking C++ code with exceptions enabled and using the ELF file
  format. While the first (partial) link appears to succeed, a second link using
  the (corrupted) output file from the partial link causes the linker to
  segfault and stop.

Workaround:
  Re-link partial linked output file with a fixed linker, then perform final
  link again with the now correct partial link output file.

-------------------------------------------------------------------------------
FIXED SDSCM00043036
-------------------------------------------------------------------------------

Summary            : Assembler generates segmentation fault

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

Release Notes:
  Assembler generates segmentation fault when compiling certain files

Workaround:
  Remove or modify the asm statement that attempts to access a C function
  parameter.

-------------------------------------------------------------------------------
FIXED SDSCM00043069
-------------------------------------------------------------------------------

Summary            : CDP instruction not accepted for v4 versions

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

Release Notes:
  The CDP instruction generates an assembler error for version v4 in arm-mode.

Workaround:
  Assemble at version v5e or higher.

-------------------------------------------------------------------------------
FIXED SDSCM00043143
-------------------------------------------------------------------------------

Summary            : Compiler incorrectly rewrites expression as rotate
                     operation

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

Release Notes:
  The problem could occur when an expression matches one of:
  x << a | y >> b if a + b = vsz
  x >> a | y << b if a + b = vsz
     x << z | y >> (vsz - z)
     x << (vsz - z) | y >> z
  
  Where:
  a and b are constant integers
  vsz is the size of x and y in bits
  
  When all of:
  x and y are expressions involving . or -> operators with the same left-hand
  sides
  x and y are of exactly the same type
  x and y are of unsigned type
  
  Effect of optimization:
  When compiler optimizer is enabled at -O1 or higher, the optimizer may
  transform equivalent code sequences into an expression which causes the
  problem to occur. For example, the sequence { int x = s.a, y = s.b; return x
  << 16 | y >> 16; } could still cause the problem despite the shift/or
  expression not directly including a . or -> operator. This includes sequences
  which may be generated as a result of function inlining.

Workaround:
  Workaround 1:
  Make sure x and y can't include structure references, for example by using
  a function such as the following to compute the expression:
  #pragma FUNC_CANNOT_INLINE(f); /* omit "(f)" in C++ */
  unsigned f(unsigned x, unsigned a, unsigned y, unsigned b) { return x << a
  | y >> b; }
  
  Workaround 2:
  Use volatile temporaries for x and y, for example:
  volatile int x = s.a;
  volatile int y = s.b;
  return x << 16 | y >> 16;

-------------------------------------------------------------------------------
FIXED SDSCM00043152
-------------------------------------------------------------------------------

Summary            : Optimizer issues information advice using optimizer's
                     temporary symbols instead of using symbols from user
                     code

Fixed in           : 5.1.0B1
Severity           : S3 - Minor
Affected Component : Optimizer

Release Notes:
  The optimiser may issue alias advice that refers to the optimiser's
  temporary symbols, whose declarations the user cannot control. This
  advice does not affect the code's behavior, though it leaves some
  suggested improvements inaccessible.
  
  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.114, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.209, 4.7.0B1 -
  4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.3, 4.7.1.201 - 4.7.1.202

Workaround:
  None. Ignore the bad advice, or try to ascertain which user variable the
  temp refers to by studying the optimiser comments in the .asm file.

-------------------------------------------------------------------------------
FIXED SDSCM00043174
-------------------------------------------------------------------------------

Summary            : Linker fails to honor specific placement for function
                     from RTS library

Fixed in           : 5.1.0B1
Severity           : S2 - Major
Affected Component : COFF Linker

Release Notes:
  Linker now honors section placement specification.

Workaround:
  Do not include libc.a option.

-------------------------------------------------------------------------------
FIXED SDSCM00043223
-------------------------------------------------------------------------------

Summary            : Compiler may miss alias given struct-of-array-of-structs

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

Release Notes:
  In a particular situation involving a struct containing an array of
  structs, the compiler may miss an alias between a read and write of a
  scalar field in the nested struct.
  
  Defect occurs in TMS470 Compiler versions: 4.8.0B1, 4.9.0B1 - 4.9.3, 5.0.0B1

Workaround:
  In this case, save pointer-written-to-struct in a temp and dereference
  from the temp instead of re-reading from struct. In general, compile at
  -o1 or -o0.

-------------------------------------------------------------------------------
FIXED SDSCM00043229
-------------------------------------------------------------------------------

Summary            : Instruction reordering alters logic

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

Release Notes:
  A sequence of code that initialises a struct by assignments to its fields,
  then copies the whole struct to another struct, then reads the fields
  individually, may sometimes read before the struct copy has happened. This
  situation has been observed when the initialisation is in an inlined function
  (and thus the struct-to-struct copy mimics the return from the callee), the
  struct read is defined within a scope that is not at top level, and another
  non-top-level scope defines a local array.

Workaround:
  No general workaround is known, aside from compiling with -o0 or -o1.. This
  specific case can be worked around by removing the extra braces around the
  bulk of the body of main(), or by inhibiting the inlining of GetPrms().

-------------------------------------------------------------------------------
FIXED SDSCM00043326
-------------------------------------------------------------------------------

Summary            : Extremely long (templated) type names may overflow
                     buffer, causing crash

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

Release Notes:
  The optimizer may crash when it encounters an extremely long type name --
  for example, a deep nested templated C++ class name -- while creating a
  printed representation. The crash is most likely, and perhaps only
  occurs, with -o2 or -o3.
  
  Defect occurs in TMS470 Compiler versions: 2.166e - 2.178e, 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.114, 4.6.0B1
  - 4.6.6, 4.4.15.200 - 4.4.15.209, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.3,
  4.7.1.201 - 4.7.1.202, 5.0.0B1

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00043468
-------------------------------------------------------------------------------

Summary            : Compiler update for Silicon Erratum Cortex-R4#57 for
                     TMS570LS3xxx

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

Release Notes:
  Please reference errata SPNZ181, Cortex-R4#57
  http://www.ti.com/lit/er/spnz181a/spnz181a.pdf
  
  The --arm_vmrs_si_workaround=on|off option was added to prevent a conditional
  VMRS instruction from being generated by the compiler. By default, the option
  is enabled (on). A warning will be emitted if a developer attempts to add a
  conditional VMRS instruction to the assembly file when the option is enabled.
  The developer can turn the option off using --arm_vmrs_si_workaround=off.

Workaround:
  None

-------------------------------------------------------------------------------
FIXED SDSCM00043538
-------------------------------------------------------------------------------

Summary            : The --unaligned_access=on option is not valid for v4 and
                     v5e architectures

Fixed in           : 5.1.0B1
Severity           : S3 - Minor
Affected Component : Shell

Release Notes:
  The ARM9 and ARM7 cores do not support unaligned accesses in the hardware.
  The compiler --unaligned_access=on option should not be used when generating
  code for these cores. For ARM11 and up, the hardware can be configured to
  support unaligned accesses. If the hardware support is enabled, the user can
  use the --unaligned_access=on option to enable the compiler to generate
  these accesses.

Workaround:
  None

-------------------------------------------------------------------------------
FIXED SDSCM00043642
-------------------------------------------------------------------------------

Summary            : Compiler incorrectly simplifies "(x >> k1) < k2" when k2
                     is constant smaller than int

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

Release Notes:
  Given an IF with a predicate like "(x >> k1) < k2", the compiler will
  attempt to convert it to "x < (k2<<k1)". If k2 is a literal or const
  variable whose type is too small to hold k2<<k1, the result will be
  incorrect. The compiler should use a wider type, the promoted type of
  x; the workaround is to do the same thing in the source.
  
  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.114, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.209, 4.7.0B1 -
  4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.4, 4.7.1.201 - 4.7.1.202, 5.0.0B2 - 5.0.0B1

Workaround:
  Declare k2 as an int instead of a shorter type.

-------------------------------------------------------------------------------
FIXED SDSCM00043705
-------------------------------------------------------------------------------

Summary            : Novel Test failure N1204B03.cpp, N1204B26.cpp

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

Release Notes:
  If a function is called twice, and in one call an argument is a
  constant (integer literal, for example) and in another call the same
  argument is a static local variable, the compiler may erroneously arrange
  to pass the constant on both calls, ignoring the actual value of the
  variable.
  
  Defect occurs in TMS470 Compiler versions: 4.6.3 - 4.6.6, 4.4.15.207 -
  4.4.15.209, 4.7.0B3 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.4, 4.7.1.201 -
  4.7.1.202, 5.0.0B1

Workaround:
  Don't use static-local variables in arguments to function calls.

-------------------------------------------------------------------------------
FIXED SDSCM00043713
-------------------------------------------------------------------------------

Summary            : Linker fails with internal error

Fixed in           : 5.1.0B1
Severity           : S2 - Major
Affected Component : Linker
Duplicate Defects  : SDSCM00043752

Release Notes:
  Linker sometimes fails with internal error: lnk<target>.exe experienced an
  unhandled exception
  
  The linker no longer makes the assumption that the decompression routine's
  section can be automatically removed when the linker determines the
  decompression routine is not needed.

Workaround:
  No workaround

-------------------------------------------------------------------------------
FIXED SDSCM00043807
-------------------------------------------------------------------------------

Summary            : Register initialization lost during instruction
                     predication

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

Release Notes:
  When converting control flow to predicated instructions, in rare cases
  the compiler could mistakenly discard some instructions which were
  unpredicatable or were already predicated. This will cause the
  generated code to work incorrectly in unpredictable ways.
  
  Defect occurs in TMS470 Compiler versions: 5.0.0B1

Workaround:
  No practical workaround

-------------------------------------------------------------------------------
FIXED SDSCM00043868
-------------------------------------------------------------------------------

Summary            : Linker cannot find include file specified with relative
                     path

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

Release Notes:
  The linker properly resets the source path after processing an #include.

Workaround:
  This bug occurs because the linker does not properly reset the source path
  after processing an #include, causing a second #include to be relative to the
  wrong path. Any intervening token between the two #include directive will
  overcome this, as will any macro expansion (even if empty). For example:
  
  #define SPACE
  #include "../first.cmd"
  SPACE
  #include "../second.cmd"

-------------------------------------------------------------------------------
FIXED SDSCM00043948
-------------------------------------------------------------------------------

Summary            : IF predicate with negative integer factor simplifies
                     incorrectly

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

Release Notes:
  An IF predicate with a negative integer factor -- eg, "if (x*(-3) == -9)"
  -- may be simplified incorrectly, for instance to "if (x == -3)" instead
  of the correct "if (x == 3)".
  
  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.116, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.209, 4.7.0B1 -
  4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.5, 4.7.1.201 - 4.7.1.202, 5.0.0B1

Workaround:
  None. Avoid the situation.

-------------------------------------------------------------------------------
FIXED SDSCM00043966
-------------------------------------------------------------------------------

Summary            : Second instance of three-operand associative op may
                     miscompile

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

Release Notes:
  If two three-operand expressions using the same associative operator and
  two of the same operands occur in the same function -- for example, x*x*x
  and 30*x*x -- the second expression may miscompile and be treated as
  identical to the first.
  
  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.116, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.209, 4.7.0B1 -
  4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.5, 4.7.1.201 - 4.7.1.202, 5.0.0B1

Workaround:
  Compile at -o1 or -o0, or avoid the situation.

-------------------------------------------------------------------------------
FIXED SDSCM00044012
-------------------------------------------------------------------------------

Summary            : Optimizer crash

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

Release Notes:
  Certain intrinsic operations are commutative -- their operands can occur
  in either order. Many of these are parallel versions of common
  commutative operations, like _add2, or specialised versions, like _smpy.
  Minimum and maximum operations also have commutative intrinsics, _min2
  and _maxu4 for example.
  
  When one of these commutative intrinsics appears in a reduction -- an
  expression like
  
    x = _op(x, k);
  
  -- inside nested loops, the optimiser may crash. It is looking for
  similar kinds of expressions, but isn't handling intrinsics correctly.
  The compiler will either produce correct code here, or crash; it will
  not silently produce incorrect code.
  
  Some of these intrinsics can be introduced by the compiler itself, based
  on the original source code. The motivating case for this bug report
  looks like
  
    for (i = a;  i < b;  i++)
      for (j = c;  j < d;  j++)
      {
        t = ...;
        if (t < min) min = t;
      }
  
  and the compiler transformed the IF into _min2.
  
  For the problem to occur, the required ingredients are a commutative
  intrinsic or expressions that can be transformed into one, inside a nest
  of two loops that are simple enough that the outer loop may be unrolled.
  The workaround is to add "#pragma UNROLL(1)" to the outer loop, or to
  compile at -o1 or -o0, to prevent the transformation where the crash
  occurs.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.5, 4.10.0B1, 5.0.0B1

Workaround:
  Try "#pragma UNROLL(1)" ahead of the outermost for-loop, or compile with
  -o1 or -o0.

-------------------------------------------------------------------------------
FIXED SDSCM00044048
-------------------------------------------------------------------------------

Summary            : Enabling vectorization produces incorrect code

Fixed in           : 5.1.0B1
Severity           : S2 - Major
Affected Component : Optimizer
Duplicate Defects  : SDSCM00045426

Release Notes:
  In certain cases, enabling vectorization could result in incorrect code
  being generated.
  
  Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.116, 4.9.0B1 -
  4.9.6, 5.0.0B1 - 5.0.0

Workaround:
  Disable vectorization or optimization.

-------------------------------------------------------------------------------
FIXED SDSCM00044066
-------------------------------------------------------------------------------

Summary            : opt470 experienced a segmentation fault

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

Release Notes:
  Corrected false assumption made while performing an optimization.

Workaround:
  No workaround.

-------------------------------------------------------------------------------
FIXED SDSCM00044216
-------------------------------------------------------------------------------

Summary            : Link time optimization produces error about option
                     --optimize_with_debug missing its argument

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

Release Notes:
  An optional parameter of on/off was added to the --optimize_with_debug
  option. During link time optimization (-o4), an internal tool incorrectly
  requires the option have a parameter, which it won't if the object file
  was built with an older tool chain. The bug has been fixed and the tool
  will accept the option with no parameter, which will be interpreted as
  --optimize_with_debug=on
  
  Defect occurs in TMS470 Compiler versions: 5.0.0B1

Workaround:
  Recompile older object files with the newer compiler, or switch back to
  using the older compiler for all stages of the build.

-------------------------------------------------------------------------------
FIXED SDSCM00044227
-------------------------------------------------------------------------------

Summary            : Compiler may not ensure uniqueness of static variables
                     in C++ templates

Fixed in           : 5.1.0B1
Severity           : S2 - Major
Affected Component : Parser
Duplicate Defects  : SDSCM00043437

Release Notes:
  In EABI mode, static variables in template functions and static data
  members of template classes may not be properly allocated and/or
  initialized. Templates are typically defined in header files, resulting in
  separate instances in each translation unit (source file). The tools must
  merge these multiple instances into unique instances, and ensure that
  static objects are allocated and initialized only once. There are three
  specific cases in which these mechanisms may fail, resulting in incorrect
  behavior of the program. They are:
  
  1. A static variable in a template function, or a static variable in a member
     function of a template class, may not be allocated as a single unique
     object. This error occurs only when all of the following conditions occur:
     - the function is not declared inline, AND
     - the function is not implicity inline by virtue of having its body defined
       within the template class, AND
     - the function body is compiled in multiple translation units (i.e. the
       definition is in a header file).
  
  For example:
  
     template <class T>
     void f()
     { 
        static int var; 
        // ...
     }
  
  If this function definition is compiled into multiple translation units, the
  compiler may incorrectly create multiple instances of 'var'.
  
  Additionally, the compiler may incorrectly allocate 'var' into a section with
  other variables. This may cause unexpected behavior during linking, such as
  incorporating of unreferenced sections into the link, or changing the contents
  of the data section from link to link (depending on which copy of 'f()'
  arbitrarily gets linked in).
  
  A workaround for this defect is to declare the function f() as inline.
  
  2. Under the same conditions described in case 1, if the static variable is
     initialized with a constructor, the constructor may incorrectly be called
     multiple times.
  
  For example:
  
     template <class T> 
     void f() 
     {
        static T var;
        // ...
     }
  
  The constructor T::T() may be called multiple times to initialize 'var'.
  Declaring f() as inline also works around this problem.
  
  3. Similarly, if a static data member of a template class is initialized with
     a constructor, the constructor may incorrectly be called multiple times.
     This occurs only when all of the following conditions occur:
     - the definition (not the declaration) of the data member appears in
       multiple translation units, AND
     - the member is referenced in multiple translation units in which the
       definition occurs.
  
  For example:
  
     template <class T>
     class MyClass
     {
        static T var;     // declaration
     };
  
     // definition
     template <class T>
     T MyClass<T>::var; // may call T::T() multiple times
  
  A workaround for case 3 is to move the definition from a header file to a .cpp
  file, so that it only occurs once.

Workaround:
  1. If a template function, or member function of a template class, has a
     static varaible, declare the function 'inline'.
  2. If a template class has a static data member with initialization by
     constructor, put the definition of the data member in a .cpp file rather
     than a .h file.

-------------------------------------------------------------------------------
FIXED SDSCM00044242
-------------------------------------------------------------------------------

Summary            : FPEXC register not properly restored before existing
                     assembly function

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

Release Notes:
  In VFPv2, the FPEXC register will be updated for any unsupported VFP
  instruction. The FPEXC register is now properly saved and restored when the
  FPEXC register might be modified inside an interrupt function when VFP is
  enabled for either VFPv2,3,4.

Workaround:
  Disable VFP support.

-------------------------------------------------------------------------------
FIXED SDSCM00044264
-------------------------------------------------------------------------------

Summary            : Internal error on 0/(-DBL_MIN/2)

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

Release Notes:
  A constant expression of the form "0 / (-DBL_MIN / 2)" will cause the
  compiler to terminate with an internal error. In floating-point
  arithmetic, this is a well-formed expression. If denormal numbers are
  supported, the correct result is -0.0. Otherwise, the result is NaN,
  and the "invalid" floating point exception may be raised.
  
  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.117, 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.6, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.1

Workaround:
  Move at least one of the operands into a variable.

-------------------------------------------------------------------------------
FIXED SDSCM00044285
-------------------------------------------------------------------------------

Summary            : scanf %[^ mistakenly writes EOF to output

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

Release Notes:
  When using ^ to negate the scan set [ sscanf(in, "%[^abc]", out) ], scanf
  would incorrectly copy EOF to the output string. It should instead stop
  reading input and return as normal.

Workaround:
  Negate the scan set manually; don't use the negation operator.

-------------------------------------------------------------------------------
FIXED SDSCM00044363
-------------------------------------------------------------------------------

Summary            : LDM instruction generates internal error: unexpected
                     operand in LDM/STM conversion

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

Release Notes:
  LDM instruction "LDM sp!, {lr}" generates internal error: unexpected operand
  in LDM/STM conversion
  
  The compiler now accepts LDM instructions with only one register in the
  register list operand.

Workaround:
  No workaround.

-------------------------------------------------------------------------------
FIXED SDSCM00044393
-------------------------------------------------------------------------------

Summary            : Linker silently ignores an output section placement spec
                     with missing ">" in the SECTIONS directive

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

Release Notes:
  When previously parsing linker command files, the linker required the ">" to
  specify memory addresses for sections (i.e. sec1 > MEM1). The ">" operator is
  now optional as the documentation states it should be.

Workaround:
  Don't omit the ">" in the linker command file.

-------------------------------------------------------------------------------
FIXED SDSCM00044450
-------------------------------------------------------------------------------

Summary            : Parser allows virtual base classes that are too large

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

Release Notes:
  In EABI, due to the RTTI implementation, the compiler can only handle
  virtual base classes of a certain size. The parser incorrectly computed
  this size and did not emit a warning for very large virtual base classes
  that were too large. This would lead to data corruption.
  
  Defect occurs in TMS470 Compiler versions: 4.1.0B1 - 4.1.7, 4.4.0B1 - 4.4.18,
  4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 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.6, 4.7.1.201 - 4.7.1.202,
  5.0.0B1 - 5.0.0

Workaround:
  Do not allow any object to inherit from virtual base classes with
  total size larger than approximately 0x7ffff0

-------------------------------------------------------------------------------
FIXED SDSCM00044474
-------------------------------------------------------------------------------

Summary            : Compiler generates Internal error: Constant table error

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

Release Notes:
  Compiler generates Internal error: Constant table error

Workaround:
  There is an issue with the compiler pass that embeds constant definitions so
  that the references to these constants efficiently reach the definitions. The
  issue manifests when encountering large string constants that are placed close
  together in straight line code.
  
  A possible workaround is to try assigning pointers to the large string
  constants and use the pointers. For example:
  
  Instead of func(parm1,parm2, "A very long string constant ....")
  
  try:
  
  const char *sptr = "A very long string constant ...";
  :
  func(parm1,parm2,sptr);

-------------------------------------------------------------------------------
FIXED SDSCM00044536
-------------------------------------------------------------------------------

Summary            : Fix to CQ44227 causes incompatible object code resulting
                     in link failure

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

Release Notes:
  The fix to CQ44227 creates an object code incompatibility with object code
  from previous toolsets, which can cause a C++ program consisting of code from
  both to fail to link.
  
  CQ44227 was an issue with static data members of template classes and
  functions, which require an initialization guard variable to insure one-time
  initialization. The guard variable was introduced into the same COMDAT section
  as the static data member.
  
  The issue is that if code from an older toolset (which does not contain the
  guard) is linked with code from a newer toolset (which does), the linker may
  choose the COMDAT group without the guard, thus leaving no definition for the
  guard. This can trigger an undefined symbol error, or, if the object code is
  in a library, cause the linker to hang.
  
  This problem occurs only under the following conditions:
  - a static variable in a template function or static data member requires
    initialization by constructor (as described in CQ44227)
  - For C6x, the program includes object code compiled by version 7.3.6 of the
    C6x compiler, as well as object code compiled by an eariler version.
  - For ARM, the program includes object code compiled by version 4.9.6 or
    5.0.0, as well as object code compiled by an earlier version.

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00044719
-------------------------------------------------------------------------------

Summary            : Linker fails with unhandled exception

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

Release Notes:
  Linker fails with unhandled exception
  
  All version 5.0.0 object file manipulation tools crash when attempting to
  read a pre-5.0.0 EABI object file with build attribute
  OFBA_ARM_Tag_compatibility set. This build attribute is not usually set. This
  means that 5.0.0 cannot be used when OFBA_ARM_Tag_compatibility is written to
  the object file.
  
  Defect occurs in TMS470 Compiler versions: 5.0.0

Workaround:
  There is no workaround.

-------------------------------------------------------------------------------
FIXED SDSCM00044735
-------------------------------------------------------------------------------

Summary            : EXIDX_CANTUNWIND yields invalid memory read

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

Release Notes:
  If an exception is thrown that tries to propagate up through any
  C-compiled function, the RTS must call std::terminate(). The linker
  is responsible for fabricating CANTUNWIND entries in the EXIDX table
  for C functions so that the unwinder knows it has unwound to a C
  function. If the C function happens to be placed after the last C++
  text section, the linker doesn't create such an EXIDX entry.
  
  This is a bug in the RTS. The EXIDX lookup does check whether it is
  running off the end of the EXIDX table, but when it does, it
  mistakenly attempts to read a value from just beyond the end of the
  table. This problem only occurs in EABI.
  
  
  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.117, 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.6, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.0

Workaround:
  This bug can only occur when the program is terminating due to a
  problem with an uncaught exception. To work around the issue, ensure
  that C++ functions which might be called from a C function catch all
  exceptions.

-------------------------------------------------------------------------------
FIXED SDSCM00044736
-------------------------------------------------------------------------------

Summary            : Loop nest over two-dimensional array compiles wrong if
                     inner loop has early exit

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

Release Notes:
  A simple loop nest that iterates over a two-dimensional array, or at
  least a data structure with two indexed parts (eg, x[i].y[j]), may
  compile incorrectly if the inner loop has a conditional break. The
  compiler converts the indexing into increments, with a correction amount
  at the end of the inner loop, and the early exit causes the converted
  code to misbehave. The listed workaround avoids the transformation and
  thus avoids the bug. The solution in the compiler is to recognise the
  early break and skip the transformation.
  
  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.117, 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.6, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.1

Workaround:
  Changing "break" to "j = 8" -- exiting early by advancing the inner loop's
  variable
  rather than by nonlocal control flow -- will work around the problem.

-------------------------------------------------------------------------------
FIXED SDSCM00044775
-------------------------------------------------------------------------------

Summary            : Missed dependence between x[i+4] and x[i] when i
                     unsigned

Fixed in           : 5.1.0B1
Severity           : S2 - Major
Affected Component : Optimizer
Duplicate Defects  : SDSCM00045067

Release Notes:
  A loop with a write to x[i+k1] and a read from x[i+k2], where i is an
  unsigned integral type and k1 and k2 are constants, may produce incorrect
  answers, because the compiler will not recognise the dependence between
  the two accesses. Whether or not the result is correct is due to
  variations in the scheduling of instructions in the compiler output. The
  compiler misses the dependences because it doesn't properly sign-extend
  the unsigned difference computation and ends up with a large positive
  number instead of the correct small negative one.
  
  Defect occurs in TMS470 Compiler versions: 4.8.0B1, 4.9.0B1 - 4.9.6,
  5.0.0B1 - 5.0.1

Workaround:
  Change "i" from unsigned to signed, from UINT32 to INT32.

-------------------------------------------------------------------------------
FIXED SDSCM00044817
-------------------------------------------------------------------------------

Summary            : Assembler reports "Illegal mnemonic" for RFEFD when
                     compiled for Thumb2

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

Release Notes:
  Assembler reports "Illegal mnemonic" for RFEFD instruction when compiled
  for Thumb2
  
  Assembler now accepts REFEA , REFFD , SRSFD, SRSEA pseudo instructions while
  in thumb mode.

Workaround:
  Change RFEFD assembly instruction to RFEIA.

-------------------------------------------------------------------------------
FIXED SDSCM00045105
-------------------------------------------------------------------------------

Summary            : Empty struct as field of parent struct may cause
                     optimizer abort

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

Release Notes:
  If a struct contains another struct, and the inner struct has no fields,
  and the parent struct is copied whole through an assignment of
  struct-type variables, the optimizer may abort.
  
  Defect occurs in TMS470 Compiler versions: 4.9.1 - 4.9.6, 5.0.0B1 - 5.0.1

Workaround:
  Add a dummy field to the empty struct.

-------------------------------------------------------------------------------
FIXED SDSCM00045211
-------------------------------------------------------------------------------

Summary            : Linker GROUP directive fails to allow NOINIT output
                     sections and regular output sections to be together in
                     the group

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

Release Notes:
  An output section that includes NOINIT sections and regular sections is
  not allowed. The code to detect this error did not properly account for
  GROUPS, which can contain a mix of section types. However, this bug
  would only occur if a GROUP was declared to be type NOINIT in the linker
  command file. The type keyword should not be applied to GROUPs, as
  documented in SDSCM00032000, and this syntax will be disallowed when
  SDSCM00032000 is fixed.
  
  Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.3

Workaround:
  None. However, the type keyword should not be applied to GROUPs.

-------------------------------------------------------------------------------
FIXED SDSCM00045232
-------------------------------------------------------------------------------

Summary            : Incorrect linker symbol value after multiple partial
                     links

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

Release Notes:
  Linker symbols whose values depend on section placement were getting
  assigned absolute values instead of section relative values in partial
  links. These are symbols that are defined using the '.' operator, and/or
  those defined using the linker command file keywords such as START, END,
  LOAD_START etc. As a result, the final link would assign incorrect values
  to these symbols.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.6, 5.0.0B1 - 5.0.1

Workaround:
  Create a large memory region in the linker command files for use during
  each partial link that defines memory starting at address zero.

-------------------------------------------------------------------------------
FIXED SDSCM00045246
-------------------------------------------------------------------------------

Summary            : Workaround for Stellaris ARM cache silicon errata

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

Release Notes:
  Added a workaround for the silicon errata as described in the
  document "Stellaris LM4FS1AH5BB Rev A1/A2". This workaround is enabled
  through the --stellaris_cache_si_workaround compiler switch.
  
  If a word-aligned value is loaded from an SRAM location into a core
  register, then altered by storing a byte or halfword at an unaligned
  offset, the altered word-aligned value is not correctly indicated when
  loaded into a core register. The loaded value from the SRAM location into
  a core register will reflect the original value, not the modified value.
  The following assembly sequence causes the altered value loaded into a
  core register to not load the correct value, even though the correct
  value is visible in the SRAM memory location:
  
    LDR R0, [SP, #+0];
    STRB R0, [SP, #+1]; (STRH can cause silicon exception as well)
    LDR R0, [SP, #+0];
  
  This assembly sequence causes erroneous values only if these three
  instructions are executed in this order. However, the three instructions
  do not have to be consecutive, which means that other instructions can be
  placed in between the first and the second instructions or the second and
  the third instructions and the false value will still occur.
  
  The solution is to insert after the STR:
  
    STR V1, [SP, #-4];
    LDR V1, [SP, #-4];
  
  This forces the cached value to be reloaded from memory
  
  The compiler switch will add the necessary extra STR, LDR instruction
  to and from the stack. The --unaligned_access=on option cannot be used
  with the --stellaris_cache_si_workaround switch. If a user tries to do
  so, a warning will be emitted and unaligned accesses will be disabled.

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00045381
-------------------------------------------------------------------------------

Summary            : Read of array element, before memcpy() overwrites it,
                     may be out of order

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

Release Notes:
  The two statements
  
    a = x[0];
    memcpy(&x[0], &x[1], K);
  
  may not occur in the correct order under certain conditions at -o2 and
  above. The memcpy() may overwrite the first element before it is saved
  in the variable. The problem is specific to memcpy().
  
  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.117, 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.3

Workaround:
  The test case is using memcpy() to implement a shift register in an
  array. More efficient, and also avoiding the problem, is to use a
  circular-queue arrangement: instead of having the head of the queue
  always be x[0] and implementing a pop by shifting the whole array, have
  the head be x[head] and implement the pop as head=(head+1)%arraysize.
  
  Or use -o1 or -o0.

-------------------------------------------------------------------------------
FIXED SDSCM00045550
-------------------------------------------------------------------------------

Summary            : Truncated pointer created by cast from integer constant

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

Release Notes:
  For an expression of the form ((t *)c1+c2), where t is an arbitrary
  type and c1 and c2 are integer constants small enough to fit in a type
  smaller than int, the optimizer could mistakenly truncate the sum of
  c1 and c2 to the smaller type. It is possible for other optimizations
  to create this expression through simplification of other expressions.
  
  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.117, 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.3

Workaround:
  Don't use the optimizer at all for source files which contain pointer
  math of the form shown in the release notes.

-------------------------------------------------------------------------------
FIXED SDSCM00045562
-------------------------------------------------------------------------------

Summary            : Multiplication by power-of-2 wider than int may use
                     wrong type

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

Release Notes:
  When multiplying a variable of a type the same size as int, or smaller,
  by a constant power of two with a type wider than int, the compiler may
  convert the multiply into a shift-left, and use the wrong type, thus
  computing the wrong answer.
  
  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.117, 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.2

Workaround:
  Make the variable the same wider-than-int type as the constant. Casting
  it may also work. Or compile at -o1 or -o0.

-------------------------------------------------------------------------------
FIXED SDSCM00045660
-------------------------------------------------------------------------------

Summary            : Different code generated on Linux and PC under the same
                     option for the same source code

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

Release Notes:
  In some cases, the same code compiled with the same version of the
  compiler may produce different asm on Windows than on Linux. The reason
  is some unstable sorting of equivalent internal rules and inlineable call
  sites. The two systems will sort differently in these cases and the
  resulting asm will vary; in some cases, performance will also be
  different.
  
  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.117, 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.2

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00045724
-------------------------------------------------------------------------------

Summary            : CCS disassembles FMRX and FMXR instructions incorrectly
                     on CortexR4

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

Release Notes:
  CCS disassembles FMRX instruction as FMXR and FMXR instruction as FMRX
  on CortexR4
  
  The assembled FMRX instruction is incorrectly disassembled as a VMSR instead
  of a VMRS instruction due to a decoding error. The assembled FMXR instruction
  is also incorrectly disassembled as a VMRS instead of a VMSR instruction.

Workaround:
  No workaround

-------------------------------------------------------------------------------
FIXED SDSCM00045742
-------------------------------------------------------------------------------

Summary            : Add support for the --symbol_map option with link time
                     optimization (-o4) is being performed

Fixed in           : 5.1.0B1
Severity           : S3 - Minor
Classification     : Enhancement
Affected Component : ILinker (File Merge)

Release Notes:
  For program level compile with --opt_level=4, previously the --symbol_map
  option was not allowed. The icode linker has been updated to handle the
  symbol_map option and --opt_level=4 will now work with symbol mapping.
  Defect occurs in ALPHA tool releases only.

Workaround:
  There is no workaround for this.

-------------------------------------------------------------------------------
FIXED SDSCM00045882
-------------------------------------------------------------------------------

Summary            : Template type not correctly resolved at parse time.

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

Release Notes:
   Template type correctly resolved at parse time.

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00046000
-------------------------------------------------------------------------------

Summary            : Fail to provide __aeabi_cdrcmple, etc in Thumb mode EABI
                     libraries

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

Release Notes:
  The following helper functions are missing from all v4, v5e, and v6 (not
  including Cortex-M0) EABI Thumb mode libraries:
  
          __aeabi_cdrcmple
          __aeabi_cfrcmple
          __aeabi_dcmpeq
          __aeabi_dcmpge
          __aeabi_dcmpgt
          __aeabi_dcmple
          __aeabi_dcmplt
          __aeabi_dcmpun
          __aeabi_dneg
          __aeabi_drsub
          __aeabi_fcmpeq
          __aeabi_fcmpge
          __aeabi_fcmpgt
          __aeabi_fcmple
          __aeabi_fcmplt
          __aeabi_fcmpun
          __aeabi_fneg
          __aeabi_frsub
  
  The following are missing from Cortex-M0 EABI libraries:
  
          __aeabi_cdcmpeq
          __aeabi_cfcmpeq
  
  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.117, 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, 4.10.0B1,
  5.0.0B1 - 5.0.3

Workaround:
  If using the TI compiler, the TI compiler presently doesn't call any
  of these functions, so no workaround should be necessary.
  
  If using any other vendor's compiler and linking with the TI
  toolchain, for v4, v5e, and v6, use the ARM mode library; for
  Cortex-M0, link with the other vendor's toolchain.

-------------------------------------------------------------------------------
FIXED SDSCM00046015
-------------------------------------------------------------------------------

Summary            : Recurrence with unsigned subscript can lead to wrong
                     answer

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

Release Notes:
  A loop with a recurrence like "x[i] = ... x[i-1] ..." or "x[i+1] = ...
  x[i] ..." may produce the wrong answers when i (or any other part of a
       complex subscript) is of an unsigned type.
  
  Defect occurs in TMS470 Compiler versions: 4.8.0B1, 4.9.0B1 - 4.9.7,
  5.0.0B1 - 5.0.3

Workaround:
  Use only signed variables for subscripts and loop index variables, or
  compile at -o1 or -o0.

-------------------------------------------------------------------------------
FIXED SDSCM00046016
-------------------------------------------------------------------------------

Summary            : Internal error for STMFD

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

Release Notes:
  When assembling for Cortex-M0, the assembler emits an internal error for the
  following instruction. It should instead emit an error message.
  
  STMFD sp!, {lr}

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00046018
-------------------------------------------------------------------------------

Summary            : MSR ASPR encoded incorrectly when ASPR is lowercase with
                     flags specified

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

Release Notes:
  The assembler will mis-encode MSR when the destination is lowercase apsr and
  flags are specified. This is true for both ARM and Thumb 2 modes, and for both
  the register and immediate versions. Examples:
  
  MSR apsr_nzcvq, r0
  MSR apsr_g, r0
  MSR apsr_nzcvqg, r0
  
  are encoded as:
  
  MSR CPSR_cxsf, R0 ; wrong flags
  MSR CPSR_, R0 ; invalid instruction
  MSR CPSR_cxsf, R0 ; wrong flags
  
  Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.2

Workaround:
  Always specify ASPR in uppercase

-------------------------------------------------------------------------------
FIXED SDSCM00046025
-------------------------------------------------------------------------------

Summary            : Incorrect save/restore code for Cortex-M0 __aeabi_drsub
                     and _dcmpun

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

Release Notes:
  The compiler calls helper functions in the library to handle basic tasks such
  as floating-point comparisons. TI's Cortex-M0 implementation of two of these
  functions, __aeabi_drsub and __aeabi_dcmpun, did not properly save and restore
  registers, and so calling these functions could corrupt the calling function's
  state, leading to unpredictable results.

Workaround:
  If using the TI compiler, the TI compiler presently doesn't call any of these
  functions, so no workaround should be necessary.
  If using any other vendor's compiler, link with the other vendor's toolchain.

-------------------------------------------------------------------------------
FIXED SDSCM00046026
-------------------------------------------------------------------------------

Summary            : Cortex-M0 __aeabi_ulcmp ignores lower 32 bits of 64-bit
                     compare

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

Release Notes:
  The compiler calls helper functions in the library to handle basic tasks such
  as 64-bit comparisons. TI's Cortex-M0 implementation of __aeabi_ulcmp ignores
  the lower 32 bits of a 64-bit comparison.

Workaround:
  If using the TI compiler, the TI compiler presently doesn't call any of these
  functions, so no workaround should be necessary.
  If using any other vendor's compiler, link with the other vendor's toolchain.

-------------------------------------------------------------------------------
FIXED SDSCM00046029
-------------------------------------------------------------------------------

Summary            : Cortex-M0 __aeabi_uldivmod fails to return ULLONG_MAX
                     for 1/0

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

Release Notes:
  ARM EABI requires that __aeabi_uldivmod return ULLONG_MAX when the divisor is
  zero and the dividend is non-zero. The TI implementation of this function for
  Cortex-M0 fails to do so.

Workaround:
  For Cortex-M0, link with another vendor's linker and RTS.

-------------------------------------------------------------------------------
FIXED SDSCM00046032
-------------------------------------------------------------------------------

Summary            : EABI rcmple functions fail to preserve A1-A4

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

Release Notes:
  The EABI states that all 6 "3-way, status-returning comparison functions
  preserve all core registers except ip, lr, and the CPSR." TI's implementation
  of __aeabi_cdrcmple and __aeabi_cfrcmple clobber A1-A4 and A1-A2 respectively.

Workaround:
  If using the TI compiler, the TI compiler presently doesn't call either of the
  affected functions, so no workaround should be necessary.
  If using any other vendor's compiler, link with the other vendor's toolchain.

-------------------------------------------------------------------------------
FIXED SDSCM00046092
-------------------------------------------------------------------------------

Summary            : Constant expressions not rounded correctly for some
                     values

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

Release Notes:
  The TI compiler supports only IEEE "round to even" mode. The compiler
  folds constant expressions using the FPSIM package. When rounding
  "exactly halfway" values, the constant folder rounded toward infinity
  rather than "round to even". This means that for some values, the
  value should be rounded *down* to the nearest even number, not up to
  an odd one. This is very unlikely to cause a problem for most
  programs; the symptom would be that the very last bit would be
  incorrect, which is a very, very small error.
  
  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.117, 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.3

Workaround:
  If maximum precision is required, avoid the use of constant float
  expressions; place each operand in a variable. The problem can also
  occur if the optimizer can determine the exact value of the operands.
  If using the optimizer, put at least one operand in a volatile
  variable.

-------------------------------------------------------------------------------
FIXED SDSCM00046190
-------------------------------------------------------------------------------

Summary            : Compiler may mishandle C symbols that resemble C++
                     mangled names (esp long sequences of underscores)

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

Release Notes:
  The compiler may mishandle C code with variables whose names resemble C++
  mangled names. The one known instances is variables with a sequence of
  four or more consecutive underscores (eg, "x_____y"). In this case, one
  pass in the compiler dropped enough of the names to mistakenly think two
  distinct variables were only one, leading to incorrect results.
  
  Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.7, 5.0.0B1 - 5.0.3

Workaround:
  Don't use variables or functions with long sequences of underscores in C
  code.

-------------------------------------------------------------------------------
FIXED SDSCM00046400
-------------------------------------------------------------------------------

Summary            : op-assign of float expression to bit-field results in
                     corrupted code

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

Release Notes:
  A bit-field may be assigned to with an op-assign (e.g. +=) operator.
  If the left hand side of the operator is a bit-field and right hand
  side is an expression with floating-point type, the compiler will in
  some cases write a corrupted value to the bit-field.
  
  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.118, 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.3

Workaround:
  Assign the value of the floating-point expression into a local integer
  variable and assign the local variable to the bit-field.

-------------------------------------------------------------------------------
FIXED SDSCM00046408
-------------------------------------------------------------------------------

Summary            : The compiler should accept the _sxth, _sxtb, _uxth, and
                     _uxtb intrinsics for Cortex-M3

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

Release Notes:
  The _sxth, _sxtb, _uxth, _uxtb intrinsics are now supported for Cortex-M3.

Workaround:
  The operations of these intrinsics can be expressed in C without intrinsics:
  
  int x;
  unsigned y;
  (short)x; // _sxth
  (signed char)x; // _sxtb
  (unsigned short)y; // _uxth
  (unsigned char) y; // _uxtb

-------------------------------------------------------------------------------
FIXED SDSCM00049564
-------------------------------------------------------------------------------

Summary            : Assembler check for CBNZ range is too lenient

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

Release Notes:
  The assembler should emit a diagnostic when a CBNZ to an out-of-range label is
  used, but it doesn't emit a diagnostic in every case that it should. It checks
  that the range is less than or equal to 128, but it should check that the
  range is less than or equal to 126. Code which uses a CBNZ (which could be
  generated by the compiler) to a label 128 bytes away will be silently accepted
  by the assembler, but will be broken.

Workaround:
  None.


===============================================================================
13. Current Known Issues
===============================================================================

The following 63 known issues exist for TMS470 Code Generation Tools release
5.1.10 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 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 SDSCM00042600
-------------------------------------------------------------------------------

Summary            : Ill advised enum scalar usage gets MISRA diagnostic, but
                     similar usage of enum array does not
Affected Component : C/C++ Compiler (cl)

Description:
  The test case given assigned a integer to an enum scalar variable. MISRA
  checking correctly flags this with a diagnostic. The test case goes on to do
  the same thing with an enum array expression. It should get the same MISRA
  diagnostic, but does not.

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

Summary            : Linker fails to warn when stack is not explicitly
                     allocated to a memory range
Affected Component : Linker

Description:
  The linker command file for the attached test case does not allocate the
  .stack section to any memory range. It also uses the --warn_sections option.
  Thus, you would expect a diagnostic stating that .stack is being allocated
  without a SECTIONS specification. However, no diagnostic is issued.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00048976
-------------------------------------------------------------------------------

Summary            : The assembler does not support UAL syntax .N and .W
                     instruction extensions when building for non-Cortex
                     devices
Affected Component : Assembler

Description:
  The ARM assembly tools manual, in the section on Unified Assembly Language
  Syntax Support, discusses UAL syntax. It says UAL syntax is supported for
  ARMv6 and earlier devices when the --ual switch is used. It also specifically
  indicates the .W and .N instruction extensions are supported.
  
  However, this test case ...
  
      .text
      .thumb
  
      bne.n dd
      nop
  dd:
      nop
  
  Does not assemble for any device ARMv6 or earlier.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00049108
-------------------------------------------------------------------------------

Summary            : Should accept cmp r9,#-32768 and turn it into cmn
                     r9,#32768 in Thumb-2 mode
Affected Component : Assembler

Description:
  The assembler should accept "cmp r9,#-32768" and encode it as "cmn r9,#32768".

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00049121
-------------------------------------------------------------------------------

Summary            : Assembler mistakenly treats qadd16 instruction as qadd
                     if presented in lowercase
Affected Component : Assembler

Description:
  Assembler mistakenly treats qadd16 as QADD but correctly handles QADD16.
  
  [ See also SDSCM00049122 ]

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00049122
-------------------------------------------------------------------------------

Summary            : ARM assembler handles lower case instructions
                     differently than upper case ones
Affected Component : Assembler

Description:
  Writing an instruction sequence in lower case can cause the assembler to
  incorrectly emit diagnostics. If these same instructions are written in upper
  case, no diagnostic is issued. Some examples include ...
  
      it eq
      addeq r9,r9,#1
  
      qsub16 r5,r14,r7
  
  [ See also SDSCM00049121 SDSCM00049110 ]

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

Summary            : Compiler misreports Misra warning 10.1
Affected Component : Parser

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

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00049356
-------------------------------------------------------------------------------

Summary            : Violation of MISRA rule 14.3 is not reported.
Affected Component : C/C++ Compiler (cl)

Description:
  The example below should flag rule 16.10 but it doesn't. Run armcl --
  check_misra=14.3
  
  extern volatile int enLocalJobId;
  #define E_CYMNG_NULL_JOB 0
  
  void foo()
  {
     while( enLocalJobId == E_CYMNG_NULL_JOB ) {;}
  }

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00049553
-------------------------------------------------------------------------------

Summary            : ARM intrinsics documentation does not match interface
                     supplied by compiler
Affected Component : Documentation

Description:
  There are many cases where the documentation for an intrinsic does not match
  the interface supported by the compiler. Two examples are:
  
  int _smmul(int src1 , int src2 , int acc ); is actually defined by the
  compiler as int_smmul (intsrc1, intsrc2); (3rd parameter is in excess).
  int _smsub(int src1 , int src2 );is actually defined by the compiler asint
  _smsub (shortsrc1, shortsrc2, inttmp); (int instead of short and missing 3rd
  parameter)
  
  All of the intrinsics need to be reviewed for possible mismatch.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00049741
-------------------------------------------------------------------------------

Summary            : In R4 big endian TI object code, CCS may not read
                     unsigned char function parameters properly.
Affected Component : C/C++ Compiler (cl)

Description:
  In R4 big endian TI object code, unsigned char arguments may be stored in 4
  bytes word.
  CCS only reads the significant bytes of the parameters and reports zeros.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00049805
-------------------------------------------------------------------------------

Summary            : ARM GCC objdump crashes when disassembling TI produced
                     executable
Affected Component : C/C++ Compiler (cl)

Description:
  Use the TI ARM compiler to build the usual hello world example program. Then
  try to use arm-none-eabi-objdump -S to disassemble it. objdump crashes. It is
  unclear whether this is a problem with the TI tools, or the GCC tools.
  
  This is definitely a bug in GNU binutils; see
  https://sourceware.org/bugzilla/show_bug.cgi?id=16822
  
  [ See also SDSCM00050016 ]

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

Summary            : LTO does not maintain mapping between input sections and
                     LTO sections for .const:.string and .init_array
Affected Component : C/C++ Compiler (cl)

Description:
  The linker must maintin a mapping between input sections and the sections
  created in the temporary lto object file. This is important because it allows
  the user to specify special placement for sections when using LTO and it
  allows the original section names to be used in the map file and diagnostics.
  If we loose this mapping, the file is reported as <whole program> and is
  confusing.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00050391
-------------------------------------------------------------------------------

Summary            : Compiler incorrectly warns that const members of a
                     struct require a constructor to be initialized
Affected Component : C/C++ Compiler (cl)

Description:
  For this code ...
  
  struct sss {
     const int i;
  };
  
  The compiler issues this diagnostic ...
  
  "file.cpp", line 1: warning: class "sss" defines no constructor to initialize
  the following:
  const member "sss::i"
  
  It is possible to initialize a struct sss variable without a constructor ...
  
  struct sss g = { 10 };

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00050841
-------------------------------------------------------------------------------

Summary            : Compiler mistakenly issues MISRA diagnostic 12.9 "The
                     unary minus operator shall not be applied to an
                     [unsigned] expression"
Affected Component : C/C++ Compiler (cl)

Description:
  For code similar to ...
  
     double_val = -1.0 * double_val;
  
  The compiler mistakenly issues the MISRA diagnostic ...
  
  "file.c", line 6: warning: (MISRA-C:2004 12.9/R) The unary minus operator
  shall not be applied to an expression whose underlying type is unsigned

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00050842
-------------------------------------------------------------------------------

Summary            : Compiler mistakenly issues MISRA diagnostic 17.6 "The
                     address of an object with automatic storage shall not be
                     assigned ..."
Affected Component : C/C++ Compiler (cl)

Description:
  For a source line similar to ...
  
     ptr_to_struct1->field = ptr_to_struct2->field;
  
  The compiler mistakenly issues the MISRA diagnostic ...
  
  "file.c", line 15: warning: (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 ("ptr_to_struct2")

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00050843
-------------------------------------------------------------------------------

Summary            : Compiler mistakenly issues MISRA diagnostic 12.2 "The
                     value of an expression shall be the same under any order
                     of evaluation"
Affected Component : C/C++ Compiler (cl)

Description:
  For a source line similar to
  
    ptr_to_struct->array[ptr_to_struct->field] = value;
  
  The compiler mistakenly issues the MISRA diagnostic ...
  
  "file.c", line 15: warning: (MISRA-C:2004 12.2/R) The value of an expression
  sha
  ll be the same under any order of evaluation that the standard permits

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00050851
-------------------------------------------------------------------------------

Summary            : Compiler may fail with INTERNAL ERROR message when
                     --check_misra=none is used
Affected Component : C/C++ Compiler (cl)

Description:
  When --check_misra=none is used, the compiler may fail with a message
  similar to ...
  
  INTERNAL ERROR: armacpia experienced a segmentation fault
  while processing function main file file.c line 10
  
  [ Appears to be Windows-only ]

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00050901
-------------------------------------------------------------------------------

Summary            : Memory access larger than the containing struct is
                     generated when accessing packed bitfields.
Affected Component : Code Generator

Description:
  The problem occurs when accessing the following field:
  
  struct __attribute__((packed) S
  {
     uint64_t x:33
  } s;
  
  s.x;
  
  Our compiler generates a 64-bit access for the field. This is incorrect since
  the struct itself is only 40 bits in size. The fundamental problem is that
  our field extraction code only supports generating a single scalar access for
  a given field. In this case we really need to generate two accesses, a 32 bit
  access followed by an 8 bit access. This could be a problem if the struct
  happens to end up next to an special memory region (end of memory,
  peripheral, etc).

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00051003
-------------------------------------------------------------------------------

Summary            : False reports of MISRA errors 10.1 and 103
Affected Component : C/C++ Compiler (cl)

Description:
  Source lines similar to these ...
  
     uint32_t *uintptr = NULL; /* sees 10.1 */
     uintptr = &(struct_ptr->a); /* sees 10.1 */
     uintptr = (uint32_t*)&(struct_ptr->a); /* sees 10.3 */
  
  ... see the MISRA errors listed. However, these source lines are correct.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00051194
-------------------------------------------------------------------------------

Summary            : Should accept MOV R0, #0x7fffffff and turn it into MVN
                     R0, #0x80000000
Affected Component : Assembler

Description:
  These instructions do exactly the same thing, but the first is not
  technically legal
  
          MOV R0,#0x7fffffff
          MVN R0,#0x80000000

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00051350
-------------------------------------------------------------------------------

Summary            : MISRA 16.4 warning on function prototypes for builtins
Affected Component : Parser

Description:
  The parser should not emit a warning for MISRA 16.4 for prototypes for
  functions that happen to be builtin functions. There's no way for the user to
  figure out what the right parameter names are.

