TMS470 C/C++ CODE GENERATION TOOLS
Defect History
4.6.6
May 2011


Table of Contents
-----------------
1. Fixed Issues in 4.6.6
2. Fixed Issues in 4.6.5
3. Fixed Issues in 4.6.4
4. Fixed Issues in 4.6.3
5. Fixed Issues in 4.6.2
6. Fixed Issues in 4.6.1
7. Fixed Issues in 4.6.0
8. Fixed Issues in 4.6.0B1
9. Known Issues


------------------------------------------------------------------------------
1. Fixed Issues in 4.6.6
------------------------------------------------------------------------------


------------------------------------------------------------------------------
FIXED  SDSCM00037878
------------------------------------------------------------------------------

Summary            : 7.0.x linker generates relocation errors for symbols
		     already in bss

Fixed in           : 4.6.6
Severity           : S3 - Minor
Affected Component : Linker

Description: 
If a partially linked out file does not include any bss variables the
linker will still create a "$bss" symbol with a value of 0.  This
ensures that if this code is linked with boot code the DP is set to
some known value.  However, if this partially linked file is later
linked with code that includes bss variables, the linker may set $bss
to an incorrect value.  This will lead to relocation errors during the
final link.

NOTE Use of several .bss output sections is not supported by the current
(6.1 and greater) linkers.  The following will generate relocation errors

	    .bsssubsect1
	    {
		 f1.out (.bsssubsect1)
		}

	    .bsssubsect2
	    {
	      f1.out (.bsssubsect2)
		}
	
	.bss
	{
	. += 0x2100;
	*(.bss)
	}

The global symbol $bss needs to be defined to the start of the .bss
section to perform the relocations. The above would have to be written
as

bss
	{
	. += 0x2100;
      f1.out (.bsssubsect1)
     f1.out (.bsssubsect2)
	*(.bss)
	}


------------------------------------------------------------------------------
FIXED  SDSCM00038834
------------------------------------------------------------------------------

Summary            : unsigned compare macro problems with Arm 4.6.x codegen

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

Description: 
The compiler is not consistently handling the part of the standard that
is implementation defined.  It isn't safe to assume that the following
would always evaluate to false

    unsigned int a;
    unsigned int b;

    a = 0x7FFFFFF0;
    b = 0x80000007;

    if (((int)(a - b)) > 0)
	printf("true\n");
    else
	printf("false\n");

Since a - b is an unsigned int value greater than INT_MAX, this 
conversion is implementation defined.  However, the TI compiler rule is
this should be a bit-by-bit copy.  For the arm tools, this appears
broken only when the compiler is used without optimization, or at level -o0. 

This bug is caused by a wrong mapping rule to map (a-b)>0? ==> (a-b)?. 
Usually happens when unsigned numbers (a-b) overflows.
  
Defect occurs in
TMS470 Compiler versions 4.6.4 - 4.6.5, 4.9.0B1 - 4.9.0B2


------------------------------------------------------------------------------
FIXED  SDSCM00039143
------------------------------------------------------------------------------

Summary            : The _call_swi intrinsic results in an internal compiler
		     error when compiler for a thumb-2
		     target

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

Description: 
This problem occurs when compiling for any Thumb-2 architecture. The
error message will be similar to

test.c, line 3 INTERNAL ERROR no match for MCALL


------------------------------------------------------------------------------
FIXED  SDSCM00039311
------------------------------------------------------------------------------

Summary            : Registers are not pushed and popped on stack in the same
		     order

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

Description: 
Issue with registers being pushed onto the stack and popped off the
stack in different orders with interrupts.


------------------------------------------------------------------------------
FIXED  SDSCM00039397
------------------------------------------------------------------------------

Summary            : Compiler incorrectly moves SDIV instruction outside of if
		     statement

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

Description: 
Given a statement like

  if (X > 0)
    loc2 = (X - Y)*100 / X;

the compiler may arrange to execute the division before the test for
zero, causing incorrect behavior if the processor traps on
divide-by-zero.  (If there is no trap, the divide-by-zero result will
be discarded and not affect the answer.)

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18


------------------------------------------------------------------------------
FIXED  SDSCM00039506
------------------------------------------------------------------------------

Summary            : optimizer pulls the memory access out of a guard which
		     causes hardware crash

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

Description: 
Given a statement like

  if (P != 0)
    loc2 = *P;

the compiler may arrange to execute the load before the test for
NULL pointer, causing incorrect behavior if the processor traps on
the bad access.  (If there is no trap, the load result will be
discarded and not affect the 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.110, 4.6.0B1 - 4.6.5, 4.4.15.200 - 4.4.15.208, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.0B2, 4.7.1.201 - 4.7.1.200


------------------------------------------------------------------------------
FIXED  SDSCM00039569
------------------------------------------------------------------------------

Summary            : Optimizer removes compare in single iteration do-while loop

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

Description: 
In the following code

    var1 = 1;
     
    do
    {
      var1--;
      if (((var1 < 1U))==0) {(foo(((unsigned char) 0x02)));};
    }
    while (var1 != 0);

the optimizer removes the compare and unconditionally calls the routine "foo". 

The conditions for this bug to occur would be

1. The loop must be a single iteration.
2. The loop induction variable must be initialized to 1.
3. The first reference to the induction variable must be an expression
that decrements the loop counter to 0.
4. The loop is a single iteration loop because the loop must break when
the induction variable is equal to 0.
5. The next reference to the loop counter must be in a compare
expression that can be reduced at compile time to (1 == 0).

Under these conditions the optimizer could remove the compare
expression causing code within the if block to execute.


------------------------------------------------------------------------------
FIXED  SDSCM00039649
------------------------------------------------------------------------------

Summary            : Compiler hangs, then reports fatal internal fault when
		     compiling certain code with -o2 and
		     higher

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

Description: 
Compiler hangs when compiling certain files with -o2 and higher, and
when the build is cancelled, it reports fatal internal fault in opt470.



------------------------------------------------------------------------------
2. Fixed Issues in 4.6.5
------------------------------------------------------------------------------

------------------------------------------------------------------------------
FIXED  SDSCM00030738
------------------------------------------------------------------------------

Summary            : Interlisting comments for an asm() statement may
		     incorrectly show it comes from an inline function

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

Description: 
The defect fix removes the inline function interlisting comment from
statements that did not originate from an inlined function.

------------------------------------------------------------------------------
FIXED  SDSCM00035166
------------------------------------------------------------------------------

Summary            : Preprocessor output should preserve pragmas

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

Description: 
The _Pragma operator is now passed to the preprocessor output.

------------------------------------------------------------------------------
FIXED  SDSCM00035387
------------------------------------------------------------------------------

Summary            : INTERNAL ERROR no match for UMCALL

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

Description: 
#pragma CODE_SIZE(func1, 32);
  #pragma CODE_SIZE(func2, 16);

  void func2()
  {
  func1();
  }

  void func1()
  {
  _disable_IRQ() // only supported in arm mode
  }

Previously, the optimizer was inlining func1 which causes the arm
mode only intrinsic _disable_IRQ() to appear inside thumb mode func2. As a
result, the codegen matcher fails to find a match for the intrinsic.  We
now inhibit function inlining for ARM when the caller/callee have different 
code states.

------------------------------------------------------------------------------
FIXED  SDSCM00037218
------------------------------------------------------------------------------

Summary            : IF with NULL-pointer check and bit test may misplace NULL
		     check

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

Description: 
A statement like

  if (p != 0 && (x & k1) == 0) *p = *p | k2;

may be rearranged incorrectly in a way that allows *p to happen whether
or not p is NULL.  For that to happen, several conditions must be
present.  The assignment must be an OR or XOR that reads and writes the
same location, k2 must be a literal integer that is a power of 2, and
the IF predicate must contain both a NULL-pointer check and a bit-test
using AND in which k1 is a power of 2.

------------------------------------------------------------------------------
FIXED  SDSCM00037294
------------------------------------------------------------------------------

Summary            : -ms causes infinite loop and internal error

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

Description: 
When compiling a testcase with -ms option the compiler hangs in
infinite loop, when the process is terminated the compiler
prints internal error message

cl470 -g -o2 -ms file.c
......

INTERNAL ERROR cg470 experienced a fatal internal fault while
		processing function _foo file file.c line 12

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.

------------------------------------------------------------------------------
FIXED  SDSCM00037361
------------------------------------------------------------------------------

Summary            : ilinker fails to merge incomplete types causing opt
		     assertion failure

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

Description: 
For this test case, a reference to a symbol is not getting its type 
resolved correctly during link time optimization. The failure to merge 
arises from the use of a type qualifier on a forward reference to a struct.  

------------------------------------------------------------------------------
FIXED  SDSCM00037398
------------------------------------------------------------------------------

Summary            : After memcpy is inlined, store to memory become write to
		     unaligned memory, STH instead of 2 STBs

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

Description: 
A call to memcpy() within a function that is inlined, when the source
or destination pointer points to a field within a struct that has a
smaller alignment than the struct itself, and the copy count is a known
constant, may lead to incorrectly-aligned memory accesses.

For example

typedef struct
{
  int pos;
  char buf[32];
} S;

f(S *p)
{
  memcpy(&p->buf[p->pos], x, 2);
}

If f() is inlined, the writes may use the alignment of S, 32 bits,
instead of the correct alignment of S.buf[], 8 bits.

------------------------------------------------------------------------------
FIXED  SDSCM00037588
------------------------------------------------------------------------------

Summary            : Functions that take a struct with a single floating point
		     member passed by value may not work correctly when VFP is 
                     enabled

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

Description: 
This bug has to do with passing structs with one double or float field
by value to a function if VFP is enabled. The function will most likely 
"lose" the field and end up using an incorrect value for the field.

------------------------------------------------------------------------------
FIXED  SDSCM00037734
------------------------------------------------------------------------------

Summary            : GCC language extension allowing arithmetic on void* and
		     function pointers generates incorrect code

Fixed in           : 4.6.5
Severity           : S2 - Major
Affected Component : Parser

Description: 
When GCC language extensions are enabled,  void* pointers and function
pointers may be used with addition and subtraction operations. 

Use of the pre- and post- increment and decrement operators, and -
operator between two pointers produce bad code with void* pointers.

Use of the pre- and post- increment and decrement operators, += 
operation, -= operator and - operator between two pointers produce bad
code with function pointers.

------------------------------------------------------------------------------
FIXED  SDSCM00037756
------------------------------------------------------------------------------

Summary            : Legal combination of GROUP, UNION, uninitialized sections,
		     and initialized sections leads to incorrect error messages

Fixed in           : 4.6.5
Severity           : S3 - Minor
Affected Component : Linker

Description: 
The test case in the detailed description combines GROUP, uninitialized
and initialized output sections, and a UNION that contains only
uninitialized sections. The linker gives error messages which indicate
the linker is trying to place an initialized section within the UNION,
even though that is not the case. 

The linker no longer issues a LOAD placement warning when a GROUP has
UNIONs which all have only uninitialized sections.

------------------------------------------------------------------------------
FIXED  SDSCM00037825
------------------------------------------------------------------------------

Summary            : ARM disassembler not outputting thumb function symbol
		     labels for linked object files

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

Description: 
The ARM disassembler now masks thumb function symbol addresses since
the address's least significant bit is set only to indicate it is a
thumb function.  

------------------------------------------------------------------------------
FIXED  SDSCM00037883
------------------------------------------------------------------------------

Summary            : INTERNAL ERROR optimizer experienced a segmentation fault

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

Description: 
A struct field with a very long name (in this case, 81 characters), 
especially if it's more than 68 characters, can lead to an optimiser 
segmentation fault when compiling with -s or -os.  The long name causes
a buffer overflow while printing the optimiser comments for the .asm
file.

------------------------------------------------------------------------------
FIXED  SDSCM00037899
------------------------------------------------------------------------------

Summary            : INTERNAL ERROR assembler experienced a segmentation

Fixed in           : 4.6.5
Severity           : S1 - Critical / PS
Affected Component : Assembler

Description: 
The assembler or linker could crash during the processing of the DWARF 
debug info that is added with the -g switch.

------------------------------------------------------------------------------
FIXED  SDSCM00038010
------------------------------------------------------------------------------

Summary            : Compiler fails to save the FPSCR in an interrupt function
		     when using VFP

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

Description: 
The FPSCR register is being modified in an interrupt function without
first being saved.

If a VFPv2/v3 compiled interrupt routine modifies the floating point
status register (FPSCR) the compiler did not save/restore the existing
value of the FSPCR register when generating code for the interrupt. 

Updated the compiler to save/restore FPSCR if

- Compiling for VFP
- The function is an interrupt
- The function modifies the FPSCR or calls another function

------------------------------------------------------------------------------
FIXED  SDSCM00038230
------------------------------------------------------------------------------

Summary            : -e option unsupported by hex470 but still displayed in tool
		     help

Fixed in           : 4.6.5
Severity           : S3 - Minor
Affected Component : Hex Converter (hex)

Description: 
The -e option has been removed from the hex utility help display.

------------------------------------------------------------------------------
FIXED  SDSCM00038262
------------------------------------------------------------------------------

Summary            : ARM compiler generates unaligned memory accesses with VFP
		     VSTR and VLDR instructions

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

Description: 
The compiler supports the packed attribute on structures for targets
that support unaligned memory accesses. There is a bug where the
compiler will generate unaligned memory accesses with VLDR/VSTR
instructions. This is a bug because these instructions must use aligned
accesses.

------------------------------------------------------------------------------
FIXED  SDSCM00038731
------------------------------------------------------------------------------

Summary            : Failure to generate COMMON section for GCC-produced object
		     file

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

Description: 
The linker will now generate .common sections for gcc produced object
files.

------------------------------------------------------------------------------
FIXED  SDSCM00038766
------------------------------------------------------------------------------

Summary            : Optimizer loses side effect in "expr % 1" - (codegen
		     contains same bug SDSCM00038778)

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

Description: 
Any expression modulo 1 -- "expr % 1" -- will be replaced by 0, because
that's what it evaluates to.  However, it is incorrect to completely 
remove "expr" if it has a side effect, such as incrementing a variable;
the correct simplification is to "(expr, 0)".

A similar problem exists for "((long)expr) / k" where the types int and
long are distinct and k > INT_MAX.

------------------------------------------------------------------------------
FIXED  SDSCM00038767
------------------------------------------------------------------------------

Summary            : Compiler emits "SDD>> internal error emit_reg_name An
		     invalid register was given" when using DWARF version 3

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

Description: 
The problem arises when using the --symdebugdwarf_version=3 and VFP
support (--float_support=vfpv3[d16]).

------------------------------------------------------------------------------
FIXED  SDSCM00038778
------------------------------------------------------------------------------

Summary            : Codegen missing increment operation - (optimizer contains
		     same bug SDSCM00038766)

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

Description: 
For any value of x, the expression 'x % 1' results in 0. The compiler 
will perform this simplification but will incorrectly not evaluate x
for side effects (eg. x++, x(), etc.). The compiler has been updated to 
evaluate x if there is a side effect.  

------------------------------------------------------------------------------
FIXED  SDSCM00038956
------------------------------------------------------------------------------

Summary            : Accessing one type through a different type misses
		     assignment - C source not allowed under C89 though

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

Description: 
The code in question is

  extern struct Y y;

    if (((X*)(&y))->b == A)
	((X*)(&y))->b = 0;

    ((X*)(&y))->arr[((X*)(&y))->b++] = B;

in which a struct of type Y is being accessed as if it were of type X.
This is not valid according to the C standards -- C99 section 6.5.7,
for example, says that an object must be accessed with its declared type.

The optimiser CSEs the read of field b across the write of 0, because
at a crucial point it compares the type of y (as an aliased variable)
against the type of the access, and because one is Y and the other X it
sees no alias.

What this patch does is extend the comparison to look not just at the
access's pointer, but also at the pointer under any casts;  in this
case, not just at the X* but also at &y which is Y*.  That addresses
CQ38956 because the idiom is consistent about pointer-casting all the
uses and the variable is always the same, but it is still easy to
construct a case where the other type can't be tracked and the
invalidity causes another error.

------------------------------------------------------------------------------
FIXED  SDSCM00039013
------------------------------------------------------------------------------

Summary            : Optimizer incorrectly optimizes ((x<<n)|y)&k

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

Description: 
In an expression like ((uc1<<8)|uc2)&0x200, where uc1 and uc2 are 8-bit
variables, the compiler can tell that uc2 is irrelevant to the result
-- all its bits are ANDed with 0. Unfortunately, in simplifying the 
expression, it interprets 0x200 with the type of uc2 and truncates it
to 0, producing incorrect code.

The problem is limited to (A|B)&C or (A&B)|C expressions, where B's
type is narrower than C's.  In this particular test case, (A|B) was an
argument to an inlined function and the AND was in the body, but other
kinds of propagation can bring the sub-expressions together.

A sample test case that demonstrates this bug follows

#include <stdio.h>

typedef unsigned char U8;
typedef unsigned short U16;
typedef unsigned int U32;

U16 parameter_mask;
U32 mask;

U8 parameters[6] = { 1, 1, 1, 1, 2, 0 };

main()
{
    parameter_mask = (parameters[5] | (parameters[4] << 8U));

    mask = 0;
    mask |= ( 0x00000001U );

    if ((parameter_mask & 0x0200) == 0x0200)
    {
	mask |= 4;
    }

    printf("simple mask = 0x%d (should be 0x5)\n", mask);
}

------------------------------------------------------------------------------
FIXED  SDSCM00039046
------------------------------------------------------------------------------

Summary            : Cannot disable MISRA checking for rule 1.1 from the command
		     line

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

Description: 
The MISRA rule 1.1 warning is no longer issued when using the
--check_misra=-1.1 option to disable it.

------------------------------------------------------------------------------
FIXED  SDSCM00039083
------------------------------------------------------------------------------

Summary            : Compiler incorrectly removes compare against zero

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

Description: 
If an unsigned integer arithmetic expression is followed by a
comparison where the result of the unsigned expression is cast to a
signed integer type, the compiler may rewrite the compare incorrectly. 
The defect can occur in the following code as an example

typedef union
{
unsigned int unsignedNum;
int signedNum;
} myType;

main()
{
myType tmp;
tmp.unsignedNum = 0xbb7U - 0x80000001U;

if (tmp.signedNum > 0) error();
}

The conversion could take place implicitly as above or with an explicit
cast. Please note that the conversion above from an unsigned to signed
is only "implementation-defined" according to the C/C++ standards.  Not
all compilers are required to generate a bit-by-bit copy and thus such
code is not fully portable.  

Also, code converting an unsigned int to signed can violate MISRA
rules. For example rule 10.1 states "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."

A compare to 0 cannot be removed when the instruction that will now set
the status bits is an unsigned instruction and there exists a branch
that uses more than the Z/N bits.  This will prevent the branch from
relying on a V bit that could be in an invalid state.

------------------------------------------------------------------------------
FIXED  SDSCM00039176
------------------------------------------------------------------------------

Summary            : Linking fails if extra space is added to linker options

Fixed in           : 4.6.5
Severity           : S3 - Minor
Affected Component : ELF Linker

------------------------------------------------------------------------------
FIXED  SDSCM00039244
------------------------------------------------------------------------------

Summary            : Compiler generates internal error "TP>> internal error Bad
		     kind  TYPEtype_pointed_to"

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

Description: 
An expression like *(x ? (T*)0xc0000000  (T*)0xc0404000) -- a
dereference of a pointer that is selected by a quest/colon, for which
one or both alternatives is a literal integer cast to a pointer type --
may cause the compiler to crash.

During other manipulations of the expression, the compiler
inadvertently discards the pointer casts and creates an invalid situation.

The requirements are a pointer-cast of a literal integer and a
quest/colon that is used as the pointer part of a memory reference.

They don't need to be written directly that way
 - The original test case used an if-then-else to choose between two
pointer-cast integers;	the compiler converted it to quest/colon.
 - The original test case used const variables that were initialised to
the integers;  the compiler propagated the constant values into the
body
of the function that used the variables.
 - The original test case used a combination of struct and array
references -- p->x[i].f -- but it was reducible to a memory access
based
on p, which was the pointer quest/colon.

------------------------------------------------------------------------------
FIXED  SDSCM00039252
------------------------------------------------------------------------------

Summary            : stdbool.h header not compatible with --gcc compiler option

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

Description: 
This bug is caused by redefinition of _Bool under non strict ANSI mode.
Mostly under --gcc. _Bool is a built-in tpye under gcc, should not be 
redefined. 


------------------------------------------------------------------------------
3. Fixed Issues in 4.6.4
------------------------------------------------------------------------------

------------------------------------------------------------------------------
FIXED  SDSCM00035000
------------------------------------------------------------------------------

Summary            : Compiler ignores #undef for a command line -D definition

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

Description: 
Take the following program tests.c

#undef foo
void foo(void)
{
}

Compile it with the C6x 7.0.0B4 compiler by

cl6x.exe -c --symdebugnone -dfoo=bar -mv6400+ --abi=eabi test.c

Display object file symbols by

nm6x.exe test.obj

The display is as follows

00000000 u
00000000 t .text
00000000 a 0276811
00000000 T bar

Obviosly the symbol foo has been renamed to bar, which should not 
happen.   The same issue pertains to the TMS470 compiler with EABI.

The assembler also accepts the -D option. As the compiler shell invokes
each pass of the compiler it is passing the -D option to the compiler 
generated assembly file.  Passing the -D to the assembler effectively 
overrides the #undef encountered by the C preprocessor. The fix will be
to avoid passing the -D/-U options to the assembler for C/CPP files.

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.105, 4.6.0B1 - 4.6.3, 4.4.15.201 - 4.4.15.207, 4.7.0B1 -
4.7.0B2

------------------------------------------------------------------------------
FIXED  SDSCM00035726, SDSCM00035817
------------------------------------------------------------------------------

Summary            : Optimizer aborted with OUT OF MEMORY error.

Fixed in           : 4.6.4
Severity           : S1 - Critical / PS
Affected Component : Optimizer

Description: 
The problem arises when a loop that implements a MAX or MIN recurrence
is 
unrolled completely, and has enough iterations that the resulting 
expression that combines all the iterations is large.  Processing this 
large expression takes excessive time or space (or both).

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.105, 4.6.0B1 - 4.6.3, 4.4.15.201 - 4.4.15.207, 4.7.0B1 -
4.7.0B2

------------------------------------------------------------------------------
FIXED  SDSCM00035917
------------------------------------------------------------------------------

Summary            : GCC language extension allowing arithmetic on void*
		     pointers generates incorrect code

Fixed in           : 4.6.4
Severity           : S2 - Major
Affected Component : Parser

Description: 
When using the --gcc option to allow GCC language extensions, the
ability to use void* pointers in arithmetic expressions is enabled.  
However, the genertated code will be incorrect.

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.105, 4.6.0B1 - 4.6.3, 4.4.15.201 - 4.4.15.207, 4.7.0B1 -
4.7.0B2

------------------------------------------------------------------------------
FIXED  SDSCM00035918
------------------------------------------------------------------------------

Summary            : Compiler fails to pass "this" pointer to a member function
		     call after the constructor is called

Fixed in           : 4.6.4
Severity           : S3 - Minor
Affected Component : Optimizer

Description: 
This really only affects -pm and -o4 usage. Even in those cases, the
optimizer may not remove the return value. Since -o4 is only supported
in version 4.7.0 and up of the ARM compiler, -pm is the only way this
bug would show up in previous builds.

------------------------------------------------------------------------------
FIXED  SDSCM00036144
------------------------------------------------------------------------------

Summary            : Disassembly incorrect for T2 BLX instruction

Fixed in           : 4.6.4
Severity           : S3 - Minor
Affected Component : Disassembler (dis)

Description: 
Fixed an issue where Thumb-2 BLX instructions were disassembled with an
incorrect destination address.

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.105, 4.6.0B1 - 4.6.3, 4.4.15.201 - 4.4.15.207, 4.7.0B1 - 4.7.0B2

------------------------------------------------------------------------------
FIXED  SDSCM00036371
------------------------------------------------------------------------------

Summary            : Address shell crash reports

Fixed in           : 4.6.4
Severity           : S3 - Minor
Affected Component : Shell

Description: 
The shell may crash on Windows with an Microsoft error dialog indicating 
a problem in ntdll.dll.  These crashes only occur on some PC's and 
seemingly at random.  The build of the shell has been changed that
should minimize the likelihood of these types of shell crashes.

Defect occurs in:

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.6.0B1 -
4.6.3, 4.7.0B1 - 4.7.0B2

------------------------------------------------------------------------------
FIXED  SDSCM00036527
------------------------------------------------------------------------------

Summary            : VFP registers popped in wrong order

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

Description: 
This bug is caused when the VFP register POP instructions are emitted
in the same order as the PUSH instructions - they should actually be
emitted in the reverse order as the PUSH instructions. This is now fixed.

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.105, 4.6.1 - 4.6.3, 4.4.15.201 - 4.4.15.207, 4.7.0B1 - 4.7.0B2

------------------------------------------------------------------------------
FIXED  SDSCM00036548
------------------------------------------------------------------------------

Summary            : Relocation entry is incorrectly evaluated to the beginning
		     of a section instead of the function symbol

Fixed in           : 4.6.4
Severity           : S3 - Minor
Affected Component : Assembler

Description: 
This bug is caused when a thumb function, say foo,  is aligned on a 
halfword boundary. The caller of foo must be in the same file, in a
different section, and in ARM mode.  Additionally, there must be some
code above foo in the same section. This situation will cause the
assembler to generate an invalid relocation entry that will cause the
caller to branch to the beginning of foo's section instead of foo
itself.

Defect occurs in:

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.6.0B1 -
4.6.3, 4.7.0B1 - 4.7.0B2

------------------------------------------------------------------------------
FIXED  SDSCM00036896
------------------------------------------------------------------------------

Summary            : Internal error on memcpy() used for value when optimization
		     is used

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

Description: 
Using memcpy() for value, as in an IF predicate or under a dereference 
operator, can result in a compiler abort if the quantity copied is a 
single instance of a scalar or struct.

Note that the return value of memcpy() is the destination pointer; 
using it for value is not often useful.

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.105, 4.6.0B1 - 4.6.3, 4.4.15.201 - 4.4.15.207, 4.7.0B1 -
4.7.0B2

------------------------------------------------------------------------------
FIXED  SDSCM00036932
------------------------------------------------------------------------------

Summary            : Compiler uses incorrect argument registers in thumb-2 mode

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

Description: 

The TMS470 thumb2 compiler contains an optimization to improve code
size by changing certain types of IT blocks into blocks of code with a
CBZ instruction replacing the IT instruction.  For example, the
following code

    CMP reg1, #0
    IT EQ
    MOVEQ reg2, reg3

is changed to

    CBNZ reg1, label
    MOV reg2, reg3
label

The defect occurs because the predicate is removed from the
instructions following the IT since it is no longer an IT block.  In
specific situations, this lost predicate can cause a different routine,
calling the routine that has this optimization, to generate incorrect
code.

Here is an example.  A function, named fun1, which takes 4 arguments,
contains this IT to CBZ optimization such that one of the argument
registers is defined in the IT block

fun1
    CBNZ A4, label
    MOV A2, A3
label
    LDR A1, [A1, #0]
    LDR A2, [A1, #0]
    BX LR

If fun1 is defined in a source file before any other routine in the
same source file that calls fun1, this bug could occur in the code
generated for the call to fun1.  The defect occurs because the argument
register A2 is defined by the move instruction following the CBNZ.  A
routine calling fun1 relies on the predicate information on an
instruction to determine the behavior of the called routine.  Since the
IT to CBZ optimization removed the predicate, the compiler incorrectly
computes that the second argument to fun1, passed in A2, is not used by
fun1.  The code generated to call fun1 will not pass the correct
argument into A2 and the defect occurs.

Conditions Necessary For SDSCM00036932

1.	The code must be compiled for thumb2.
2.	The code must be compiled with optimization level -o2 or
higher.
3.	The code is not compiled for speed.  The build does not include
the --opt_for_speed, or -mf, switch.	Without a value, -mf defaults
to -mf=4.  This bug does not occur at -mf=3 or higher.  It can
occur with -mf=2 or lower. 
4.	The called routine, as described above, must occur in the same
file where the calls occur.  Calls across files are not affected by
this bug.
5.	The called routine must be defined in the source before any
routine that calls the affected function.
6.	The called routine must contain arguments.
7.	The called routine must include a CBZ or CBNZ instruction that
is followed by an instruction that conditionally defines one of the
argument registers.  There can be no preceding reference to this
argument register prior to the CBZ.

With these conditions, any routine calling this affected function could
generate incorrect code to set up the arguments to the affected
function.

------------------------------------------------------------------------------
FIXED  SDSCM00036956
------------------------------------------------------------------------------

Summary            : Compiler gives error "Offset out of range" when compiled
		     for Thumb-2

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

Description: 
The compiler is generating the following incorrect instruction

LDRB	  A1, [A1, #-2147483648]

This causes the assembler to generate an error

test.asm", ERROR!   at line 377 [E0200] Offset out of
								 
range, must be
								 
[-255,4095]

------------------------------------------------------------------------------
FIXED  SDSCM00036985
------------------------------------------------------------------------------

Summary            : Compiler generates a CRET instruction in an ARM function to
		     call a thumb function in the same file

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

Description: 
This bug can occur if two functions in the same file are in different 
states, one in ARM the other in Thumb. If the ARM function qualifies
for tail call optimization, then its BL instruction to the Thumb function 
will be converted to a CRET (pseudonym for B) instruction. If the thumb
function happens to fall on a halfword boundary, the assembler will
issue an error.

Defect occurs in:

TMS470 Compiler versions 4.4.19 - 4.4.18, 4.5.3 - 4.5.2, 4.6.4 - 4.6.3,
4.7.0B3 - 4.7.0B2

------------------------------------------------------------------------------
FIXED  SDSCM00037009
------------------------------------------------------------------------------

Summary            : Left-shift by one less than signed type's size can compile
		     incorrectly

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

Description: 
The test case involved first contained a left shift of a signed int by
31.  This expression is undefined according to the C standard.	The
expression also contained a right shift of a negative signed int.  This
is implementation-defined according to the C standard. A legal
expression can be written as:

S32 mask00 = ((S32)((U32)(mask[0] > 0) << 31) >> 31);

Perform an unsigned left shift, cast the result to signed and then
perform the right shift.  This gives the result you expect with an optimization
level less than -o3.	At level -o3, the optimizer does not sign extend the
right shift and reduces the expression to 1.	This is a bug, since the
implementation-defined behavior should be consistent in the tools.

Note that -o3 is relevant only in that it allows automatic inlining and
thus perturbs the code.  The key detail is the shift of 1 by 31 bits
and conversion to signed;  a smaller shift, or if there were no signed
types involved, and the problem would not occur.

Defect occurs in:

TMS470 Compiler versions 2.166e - 2.177e, 2.209e, 2.40.beta - 2.71,
4.1.0B1 - 4.1.7, 2.54.02 - 2.54.208, 2.54.03 - 2.54.127, 2.202.03e -
2.202.14e, 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.106,
4.6.0B1 - 4.6.3, 4.4.15.200 - 4.4.15.207, 4.7.0B1 - 4.7.0B2

------------------------------------------------------------------------------
FIXED  SDSCM00037083
------------------------------------------------------------------------------

Summary            : ARM compiler generates incorrect code for VFP multiply
		     accumulate negate (VNMLA) instruction

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

Description: 
ARM VFP instructions for float and double VNMLA, multiply accumulate 
negate, are generated incorrectly as VMLS, multiply subtract 
instructions.  This pertains to source code that has the specific form
c = -(c+(a*b)) where c, a and b are floats or doubles.  Other equivalent
variations of source code such as c = -c - (a*b) do not produce
incorrect results.

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.106, 4.6.0B1 - 4.6.3, 4.4.15.201 - 4.4.15.208, 4.7.0B1 - 4.7.0B3

------------------------------------------------------------------------------
FIXED  SDSCM00037225
------------------------------------------------------------------------------

Summary            : Compiler for ARM v7 targets with VFP formats assembly
		     instructions "FCMPESZ" and "FCMPEDZ" incorrectly

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

Description: 
Compiler for ARM v7 targets with VFP formats assembly instructions
FCMPESZ and FCMPEDZ incorrectly.  These instructions should be FCMPEZS
and FCMPEZD.  

Defect occurs in:

TMS470 Compiler versions 4.6.0B1 - 4.6.3, 4.7.0B1 - 4.7.0B3


------------------------------------------------------------------------------
4. Fixed Issues in 4.6.3
------------------------------------------------------------------------------

------------------------------------------------------------------------------
FIXED  SDSCM00008363
------------------------------------------------------------------------------

Summary            : Link-time errors with assert pragma

Fixed in           : 4.6.3
Severity           : S3 - Minor
Affected Component : Linker

Description: 
The issue is how the compiler handles the assert pragma. The pragma is 
considered an intrinsic by the compiler. It uses the assertion
expression to obtain information in order to perform optimization. Before 
the intrinsic was turned into a call to _abort_msg, the optimizer consider
the function "dead" and removed the definition of it. This also caused
the fflush() function to be removed as well. When the linker tried to
bring fflush() back into the link, it also had to bring _doflush() 
because they are defined in the same file. This caused the redefinition
error.	The compiler now will not delete the _abort_msg function.

Defect occurs in:

TMS470 Compiler versions 4.1.0B1 - 4.1.7, 4.5.0B1 - 4.5.2, 4.6.0B1 -
4.6.2

------------------------------------------------------------------------------
FIXED  SDSCM00034702
------------------------------------------------------------------------------

Summary            : "Optimizer terminated abnormally" error with Incomplete
		     array type

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

Description: 
The optimiser may abort when presented with a variable with an
incomplete array type (ie, an array with no dimensions, "extern int x[]"), 
if it is able to vectorise an access involving that variable but some 
internal bookkeeping messes up.

------------------------------------------------------------------------------
FIXED  SDSCM00034797
------------------------------------------------------------------------------

Summary            : Compiler error when TMP environment variable contains
		     spaces in the path

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

Description: 
If the TMP environment variable contains spaces, such as 

"C\Documents and Settings\..." 

then the compile fails with an error about not finding a file "C\Documents".  
If TMP is changed so that it uses the short path names (C\Docume~1\...) then 
it works.

The bug has been fixed and the compiler no longer fails when the TMP 
environment variable contains spaces in the path.

Defect occurs in:

TMS470 Compiler versions 4.6.1 - 4.6.2

------------------------------------------------------------------------------
FIXED  SDSCM00034933
------------------------------------------------------------------------------

Summary            : Disassembler mishandles .cinit section when it has separate
		     load and run address

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

Description: 
Originally the elf linker did not support having separate load and run 
addresses for cinit sections.  When the linker was updated (4.6) to 
support this the disassembler was not updated. 

Updated disassembler to process cinit sections allocated to different
run and load addresses.

Defect occurs in:

TMS470 Compiler versions 4.6.2

------------------------------------------------------------------------------
FIXED  SDSCM00034995
------------------------------------------------------------------------------

Summary            : VSTM instruction w/o optional mode specified fails for
		     Cortex-R4

Fixed in           : 4.6.3
Severity           : S2 - Major
Affected Component : Assembler

Description: 
The bug here is that the encoding T2 / A2 VFPv2, VFPv3 for
VSTM{mode}<c> <Rn>{!}, <list> where mode is optional does not work 
under 4.6.2. Illegal mnemonics instructions is issued for instruction 
versions like
       
		   VSTM R1, {D0-D4};

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.104, 4.6.2, 4.4.15.201 - 4.4.15.205, 4.7.0B2 - 4.7.0B1

------------------------------------------------------------------------------
FIXED  SDSCM00035082
------------------------------------------------------------------------------

Summary            : Including math.h inside extern "C" gives errors

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

Description: 
math.h is responsible for defining some overloaded functions when in
C++ mode, but it should not do so when included under an extern "C"
specifier.  This will cause compiler errors in C++ source

extern "C" { 
#include <math.h>
};

You can work around the problem by moving the include directive outside
of the 'extern "C"'.

------------------------------------------------------------------------------
FIXED  SDSCM00035153
------------------------------------------------------------------------------

Summary            : CGT Optimizer terminated abnormally

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

Description: 
The compiler may abort if given a function call with an argument that
is a struct passed by value, if the struct is small enough to fit into an 
int and compilation is for the COFF ABI.

Defect occurs in:

TMS470 Compiler versions 2.166e - 2.177e, 2.209e, 2.40.beta - 2.71,
4.1.0B1 - 4.1.7, 2.54.02 - 2.54.208, 2.54.03 - 2.54.126, 2.202.03e -
2.202.14e, 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.104,
4.6.0B1 - 4.6.2, 4.4.15.200 - 4.4.15.205, 4.7.0B1

------------------------------------------------------------------------------
FIXED  SDSCM00035269
------------------------------------------------------------------------------

Summary            : compiler generates ADR instruction with an invalid offset

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

Description: 
The compiler embeds constants in the .text section. It attempts to 
allocate all uses of a constant to a single definition, but sometimes
it is necessary to duplicate constants because of the limited range of LDR
and ADR instructions. This was a situation where constants were being 
duplicated, only to be found out they weren't needed. The compiler 
mistakenly wrote out these unneeded constants, pushing other constants 
out of range. This bug is most likely to be exposed when using -mf3 or
higher with compiler release 4.7.0 or higher.

Defect occurs in:

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.6.0B1 -
4.6.2, 4.7.0B1 - 4.7.0B2

------------------------------------------------------------------------------
FIXED  SDSCM00035306
------------------------------------------------------------------------------

Summary            : The compiler may produce incorrect code when a static local
		     variable appears as part of an argument to a function call

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

Description: 
The compiler may produce incorrect code when a static local variable 
appears as part of an argument to a function call, when the same 
expression is used for that argument in all calls to that function, and
compilation uses -o3 optimisation.  There is a conflict between local 
statics and an aspect of -o3.

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.104, 4.6.0B1 - 4.6.2, 4.4.15.200 - 4.4.15.205, 4.7.0B1 -
4.7.0B2

------------------------------------------------------------------------------
FIXED  SDSCM00035418
------------------------------------------------------------------------------

Summary            : Bitwise ops on memory access may go wrong if opASG in
		     register promotion

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

Description: 
OpASGs involving bitwise operations, especially &=, may compile 
incorrectly when used in a context in which the compiler wants to
promote a memory access to a register.	For example, "x.a.b &= k" when 
there are several uses of x.a.b in the function; the compiler will move 
x.a.b to a register during the function and write it back at the end, but 
this problem may cause it to lose the "&= k" part.

Defect occurs in:

TMS470 Compiler versions 4.4.19 - 4.4.18, 4.5.3 - 4.5.2, 4.4.10.100 -
4.4.10.104, 4.6.2, 4.4.15.205, 4.7.0B1 - 4.7.0B2

------------------------------------------------------------------------------
FIXED  SDSCM00035422
------------------------------------------------------------------------------

Summary            : When building a relocatable executable, linker omits
		     relocation entries from the .debug_info section

Fixed in           : 4.6.3
Severity           : S2 - Major
Affected Component : COFF Linker

Description: 
When building a relocatable executable (-a -r) linker options, the
linker may omit some relocations from the .debug_info section. This can
inhibit debugging if the file is subsequently relocated.

------------------------------------------------------------------------------
FIXED  SDSCM00035505
------------------------------------------------------------------------------

Summary            : Given a certain placement for .data, initialization data is
		     not relocated under EABI

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

Description: 
The given linker command file exposes a linker issue that prevents the 
initialization data for the function pointer 'Tests' array from being 
relocated. 

------------------------------------------------------------------------------
FIXED  SDSCM00035558
------------------------------------------------------------------------------

Summary            : Fix shell memory allocation errors in the compiler shell

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

Description: 
The shell could crash if the host OS were to run out of available heap
memory.  The shell would not report any "out of memory" error.	


------------------------------------------------------------------------------
5. Fixed Issues in 4.6.2
------------------------------------------------------------------------------

------------------------------------------------------------------------------
FIXED  SDSCM00033570
------------------------------------------------------------------------------

Summary            : Incorrect encoding for MVN instruction

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

Description: 
This bug is a result of the assembler performing arithmetic in a 
precision larger than 32 bits. In this particular case, the result 
becomes negative as a result of the bit-wise not operator. Then the 
assembler saturated the value when it was converted to a 32 bit
constant, which resulted in 0x80000000. The assembler will now truncate the
result to 32 bits and not saturate overflows.

Defect occurs in:

TMS470 Compiler versions 2.71, 4.1.7, 2.54.208, 2.54.126, 4.4.16 -
4.4.17, 4.5.2, 4.4.10.104, 4.6.0 - 4.6.1, 4.4.15.202 - 4.4.15.204

------------------------------------------------------------------------------
FIXED  SDSCM00033854
------------------------------------------------------------------------------

Summary            : The compiler ignores all but the last --preinclude option

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

Description: 
Instead of processing multiple --preinclude options as documented, the
compiler shell will only process the last --preinclude option that appears on
the command line if more than one is specified.

Defect occurs in:

TMS470 Compiler versions 4.4.0B1 - 4.4.17, 4.5.0B1 - 4.5.2, 4.4.10.104,
4.6.0B1 - 4.6.1, 4.4.15.201 - 4.4.15.204

------------------------------------------------------------------------------
FIXED  SDSCM00034111
------------------------------------------------------------------------------

Summary            : Hex converter issues warning about a section falling in
		     unconfigured memory when creating a load image with no ROMS 
		     directive

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

Description: 
This bug affects the default load image section layout of the hex
utility. If the load address of a section is larger than 0x80000000, it
may not be included in the resulting load image object file.

Defect occurs in:

TMS470 Compiler versions 4.6.1

------------------------------------------------------------------------------
FIXED  SDSCM00034181
------------------------------------------------------------------------------

Summary            : The optimizer crashes when compiling with -o2 or higher in
		     combination with -mf3 or higher

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

Description: 
A loop structured something like

  for (x = 0;  x < N;  x++)
  {
    y = f();
    if (x == 1) y = g();
    else if (P) ... y ...;
    else	...;
  }

may, if the loop unrolls, cause the optimiser to abort.  The key detail
is that a section of the code only applies to a single iteration of the
loop, and some uses of a variable are within that section and some 
aren't.  When the loop is unrolled, some instances of that section will
be deleted, and the optimiser can fail to properly track the variable's
uses.

Defect occurs in:

TMS470 Compiler versions 4.5.0B1 - 4.5.2, 4.6.0B1 - 4.6.1

------------------------------------------------------------------------------
FIXED  SDSCM00034228
------------------------------------------------------------------------------

Summary            : Codegen seg fault

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

Description: 
This bug can occur when performing optimization and compiling with -mf2
or below. 

Defect occurs in:

TMS470 Compiler versions 4.4.0B1 - 4.4.17, 4.5.0B1 - 4.5.2, 4.6.0B1 -
4.6.1

------------------------------------------------------------------------------
FIXED  SDSCM00034230
------------------------------------------------------------------------------

Summary            : Codegen assertion failure

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

Description: 
This bug will most likely affect customers using the -pm option. It is 
caused by an overflow of a counter. 

Defect occurs in:

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.6.0B1 -
4.6.1

------------------------------------------------------------------------------
FIXED  SDSCM00034351
------------------------------------------------------------------------------

Summary            : linker generates unnecessary trampoline calls regardless of
		     callee's address is within a normal call range

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

Description: 
Previously targets like ARM would not generate trampolines to absolute
addesses because there was no information about the callee's mode, so
the linker could not generate the correct call veneer to the callee.
Now, this behavior was modified for SDSCM00033697, fixed in ARM
compiler release 4.6.1.  When these trampolines were generated
appropriate warnings are generated.  After the 33697 fix was put in
place, the linker was generating an un-needed trampoline, because in
the testcase the symbol was reachable yet a trampoline was generated.
In the testcase, the callee was an absolute symbol belonging to a yet
unplaced DSECT. Since the absolute symbol was defined in terms of a dot
expression, it's value could not be known until the section was placed.
  
The fix was to get location information from the symbol's parents, and
use that information to determine if the callee was "far" from the
caller, and if a trampoline was needed.

------------------------------------------------------------------------------
FIXED  SDSCM00034533
------------------------------------------------------------------------------

Summary            : project fails with -o1 and above but passes with -o0

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

Description: 
A loop which declares and initialises a const variable may cause the
compiler to mistakenly propagate the variable into its uses.  Const
within a loop means constant for a single iteration, but the compiler
may sometimes interpret it as constant throughout the function.

------------------------------------------------------------------------------
FIXED  SDSCM00034557
------------------------------------------------------------------------------

Summary            : Compiler incorrect handling arithmetic with mixed types

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

Description: 
An expression like "x->us += l", where "us" is an unsigned field
shorter than int and "l" is a variable longer than int that may contain
a negative value, may compile incorrectly when it occurs in a loop or
other control structure that has multiple uses of "x->us".  The
compiler will try to copy "x->us" to a temporary variable to avoid
repeating the memory reference, but it may lose the narrowing cast that
comes with an assignment to a shorter-than-int type.


------------------------------------------------------------------------------
6. Fixed Issues in 4.6.1
------------------------------------------------------------------------------

------------------------------------------------------------------------------
FIXED  SDSCM00019490
------------------------------------------------------------------------------

Summary            : Add support for ISB, DSB, and DMB intrinsics 

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

Description:
The following intrinsics are now available when compiling for a V7
architecture.

void _isb();

When called, will generate the ISB instruction.

void _dsb();

When called, will generate the DSB instruction.

void _dmb();

When called, will generate the DMB instruction.

------------------------------------------------------------------------------
FIXED  SDSCM00029529
------------------------------------------------------------------------------

Summary            : ARM VFP argument passing is susceptible to corruption

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

Description:
According to the ARM calling conventions, the VFPv2 coprocessor
registers S0-15(D0-D7) can be used to pass floating point parameters.
Once these registers have all been allocated, any remaining floating
pointer parameters are expected to be passed on the stack.

When compiling with VFPv2 support, the compiler continued to allocate
floating point parameters to the remaining VFP registers. As a result,
in the rare case where more than 16 single precision floating point 
values, or 8 doubles, or a combination of floats/doubles requiring 
more than 16 words of float values are in a function's parameter list
the compiler will violate the calling convention.  

In the extreme case where there are more floating point parameters than
 there are VFP registers, an internal error would result when compiling.

This defect occurs in 

TMS470 Compiler versions 4.4.0 - 4.4.17, 4.5.0B1 - 4.5.2, 
4.4.10.100 - 4.4.10.104, 4.6.0B1 - 4.6.0, 4.4.15.201 - 4.4.15.202

Workaround:
Avoid passing more than 16 words worth of float/double arguments in
a function's parameter list.


------------------------------------------------------------------------------
FIXED  SDSCM00029984
------------------------------------------------------------------------------

Summary            : Compiler generates incorrect code in some cases at
                     certain optimization levels.

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

Description:
Code of approximately the form

  a->b = a->b + k;
  if (...) ... = a->b;

may compile incorrectly, such that the last a->b isn't re-read but instead 
reuses the value from before the assignment.  The problem tends to only 
occur when the above code is used in the context of a large program.
Attempts to reduce the test case will likely make the problem go away.

This defect occurs in

TMS470 Compiler versions 4.1.0B1 - 4.1.7, 4.4.0B1 - 4.4.16, 4.5.0B1 -
4.5.2, 4.4.10.100 - 4.4.10.104, 4.6.0B1 - 4.6.0, 4.4.15.200 -
4.4.15.202

Workaround:
Move a->b into a local variable before using it.  Compiling at a
different optimisation level can help;  this particular instance
happens only at -o1, not at -o0, -o2, or -o3.  

Avoiding use of the -pm option may also help.

------------------------------------------------------------------------------
FIXED  SDSCM00030501
------------------------------------------------------------------------------

Summary            : Copy table compression is disabled if there is only one
                     copy table record

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

Description:
This is a linker bug. It happens when there is only one copy table
record, the compression request is ignored by the linker
Defect occurs in

TMS470 Compiler versions 4.4.0 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100 -
4.4.10.104, 4.6.0B1 - 4.6.0, 4.4.15.200 - 4.4.15.202

Workaround:
There is no work around for this bug.

------------------------------------------------------------------------------
FIXED  SDSCM00031309
------------------------------------------------------------------------------

Summary            : Compiler generates incorrect code for recursive 
                     function when compiling with -mv7m3

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

Description:
This defect will only occur when:
 - Compiling for Cortex M3 (-mv7m3 -mt)
 - using compile for speed option -mf >= 3
 - using optimization level > 0

Condition can be avoided if compiling with debug.

This defect occurs in

TMS470 Compiler versions 4.5.0B1 - 4.5.2, 4.6.0B1 - 4.6.0


Workaround:
The defect can be avoided if you compile:
- using compile for speed option -mf of < 3, or
- using no optimization, or
- using debug option, -g.

------------------------------------------------------------------------------
FIXED  SDSCM00032236
------------------------------------------------------------------------------

Summary            : Array alignment is not optimal when compiling in EABI
                     mode

Fixed in           : 4.6.1
Severity           : S3 - Minor
Affected Component : Optimizer

Description:
A global array variable may not get an optimal word alignment in EABI
mode even when this should be possible.  If an array variable contains
an extern declaration prior to the variable definition this can prevent
the compiler setting a more optimal word alignment.

Workaround:
Remove extern declaration of the array variable.

------------------------------------------------------------------------------
FIXED  SDSCM00032270
------------------------------------------------------------------------------

Summary            : The assembler does not accept the MRC mnemonic for
                     Cortex-M3

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

Description:
Updated the assembler to accept the instructions

MRC, MRRC, MCR, MCRR, MRC2, MRRC2, MCR2, MCRR2

when compiling for Cortex M3.

This defect occurs in

TMS470 Compiler versions 4.4.0 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100 -
4.4.10.104, 4.6.0B1 - 4.6.0, 4.4.15.201 - 4.4.15.202


Workaround:
Instructions are accepted as expected when compiling for R4.

------------------------------------------------------------------------------
FIXED  SDSCM00032292
------------------------------------------------------------------------------

Summary            : Compiler incorrectly handles code that requires 
                     pointer equality of string literals

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

Description:
If a function is called with a string-literal argument, when compiling
with -o3 and --gen_func_subsections, and the callee is only ever called
with the one string, then an optimization may copy the string into the
callee's body and create two identical strings that aren't the same
object.  If string pointer equivalence is important, this combination 
can cause incorrect results.

This defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.17, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.104, 4.6.0B1 - 4.6.0, 4.4.15.200 - 4.4.15.204

Workaround:
Compile at -o2, or modify the code to not require pointer equality of
string literals.

------------------------------------------------------------------------------
FIXED  SDSCM00032706
------------------------------------------------------------------------------

Summary            : Compiler generates internal error during parse phase

Fixed in           : 4.6.1
Severity           : S2 - Major
Affected Component : Parser

Description:
When compiling with --abi=eabi and --exceptions a parser segfault may
result if a function is declared using a user defined typedef and is
later called.

For example:

typedef int MYFUNCTYPE(void);

MYFUNCTYPE init;

init();

This defect occurs in

TMS470 Compiler versions 4.4.17, 4.5.2, 4.4.10.104, 4.6.0, 4.4.15.202


Workaround:
Avoid using typedefs (uncommon) for function declarations.

------------------------------------------------------------------------------
FIXED  SDSCM00033099
------------------------------------------------------------------------------

Summary            : Compiler generates incorrect code for bit-field to 
                     bit-field assignments done with optimization

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

Description:
An assignment like "a.b = c.d", where both b and d are bitfields, the
type of d is narrower than the type of b, and b's position in its
container type is beyond what d's type can represent, may be compiled
incorrectly in a way that truncates the value assigned to a.b.

This defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.17, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.104, 4.6.0B1 - 4.6.0, 4.4.15.201 - 4.4.15.202

Workaround:
Use "int" for the type of all bitfields.

------------------------------------------------------------------------------
FIXED  SDSCM00033161
------------------------------------------------------------------------------

Summary            : Linker is corrupting the content of the .cinit section
                     when Thumb code is combined with uninitialized sections
		     like .bss

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

Description:
This defect can occur when initialized sections containing Thumb code are
combined with uninitialized sections, specifically .bss. This
combination can result from GROUP-ing the sections together in the
linker command file, or from including text sections in .bss, again via 
the linker command file. 

Avoiding such a combination should prevent this problem.

This defect occurs in

TMS470 Compiler versions 4.4.1 - 4.4.17, 4.5.0B1 - 4.5.2, 4.4.10.100 -
4.4.10.104, 4.6.0B1 - 4.6.0, 4.4.15.201 - 4.4.15.204

Workaround:
Avoid combining initialized text sections with uninitialized data
sections in the linker command file. 

For example, avoid placement of a .text section within .bss, i.e.

.bss { file.obj (.textfunction_name)}.

------------------------------------------------------------------------------
FIXED  SDSCM00033385
------------------------------------------------------------------------------

Summary            : hex utility is incorrectly padding a section when
                     creating a load image object file

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

Description:
Users can encounter this defect if there is a section which does not end
on a word aligned boundary, and there is another section (most likely a
fill section), which starts at the end of that section.

This would cause the hex utility to pad the first section with the hex
utility's fill value, and then ignore the fill section. Unless the user
is relying on a specific value for the fill value, the resulting object 
file should work correctly.

With this fix, the original fill section will be incorporated in the
load image object file.

This defect occurs in

TMS470 Compiler versions 4.6.0B1 - 4.6.0

Workaround:
Use the .palign directive in the linker command file to cause the output
section to be padded to the target's word size.

------------------------------------------------------------------------------
FIXED  SDSCM00033398
------------------------------------------------------------------------------

Summary            : Compiler does not accept a 'while() do' as the last 
                     statement in a statement expression

Fixed in           : 4.6.1
Severity           : S2 - Major
Affected Component : Parser

Description:
This defect only happens in --gcc mode. It is caused when a compound 
statement is specified as the last statement in a statement expression.

This defect occurs in

TMS470 Compiler versions 2.71, 4.1.7, 2.54.208, 2.54.126, 4.4.16 -
4.4.17, 4.5.2, 4.4.10.104, 4.6.0, 4.4.15.202

Workaround:
There is no work around for this problem

------------------------------------------------------------------------------
FIXED  SDSCM00033405
------------------------------------------------------------------------------

Summary            : Compiler generates incorrect code in some cases when
                     a volatile argument is passed by value

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

Description:
This defect can occur if volatile arguments are passed by value, or a 
volatile pointer to a class/struct member to a function.  The compiler 
attempted to copy volatile arguments passed by value to a temporary
location, similiar to if the compiler encounters a statement of the form:

x;

where x is a volatile. 

This defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.104, 4.6.0B1 - 4.6.0, 4.4.15.201 - 4.4.15.202

Workaround:
To avoid this defect, you can change the order of the arguments by
passing the volatile arguments first. Also, invoking the opimizer will 
likely cause the issue to be resolved.

------------------------------------------------------------------------------
FIXED  SDSCM00033448
------------------------------------------------------------------------------

Summary            : Compiler generates internal error when processing
                     a loop contained in a statement expression

Fixed in           : 4.6.1
Severity           : S2 - Major
Affected Component : Parser

Description:
This defect can only occur when using the --gcc option.

The defect happens when some symbols (variables, functions, etc.) are
extracted from statement expressions in a FOR/WHILE loop as part of
statement expression processing. The compiler fails to register these 
symbols as needed and so their definitions are missing from the compiler's
intermediate representation.

This defect occurs in

TMS470 Compiler versions 2.71, 4.1.7, 2.54.208, 2.54.126, 4.4.16 -
4.4.17, 4.5.2, 4.4.10.104, 4.6.0, 4.4.15.202

Workaround:
There is no work around for this problem.

------------------------------------------------------------------------------
FIXED  SDSCM00033490
------------------------------------------------------------------------------

Summary            : Compiler incorrectly swaps a store and load to the same
                     structure member

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

Description:
A read and a write to the same struct field, accessed through a
restricted pointer that is derived from another restricted pointer, may
occur in the wrong order.

This defect occurs in

TMS470 Compiler versions 2.166e - 2.177e, 2.209e, 2.40.beta - 2.71,
4.1.0B1 - 4.1.7, 2.54.02 - 2.54.208, 2.54.03 - 2.54.126, 2.202.03e -
2.202.14e, 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.104,
4.6.0B1 - 4.6.0, 4.4.15.200 - 4.4.15.202

Workaround:
Leave "restrict" off the pointers involved, or use -o1 or -o0 instead
of -o2 or -o3.

------------------------------------------------------------------------------
FIXED  SDSCM00033532
------------------------------------------------------------------------------

Summary            : Compiler generates LDW and STW in incorrect order

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

Description:
A read and write to the same struct field may occur in the wrong order in
certain obscure circumstances involving link-time recompilation.

This defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.104, 4.6.0B1 - 4.6.0, 4.4.15.200 - 4.4.15.202

Workaround:
It is possible that the problem arose from incomplete struct types in
one of the files;  try ensuring that struct types are always completely
defined.  If that doesn't help, avoid link-time recompilation or compile
with -o1 or -o0 instead of -o2 or -o3.

------------------------------------------------------------------------------
FIXED  SDSCM00033636
------------------------------------------------------------------------------

Summary            : Compiler generates incorrect code for structure 
                     compare statements during optimization

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

Description:
A loop containing a sequence (possibly not contiguous) like

  a[i] = k;
  x    = a[i];

may compile incorrectly if the loop is unrolled and the compiler attempts
to combine the stores to a[i] and a[i+1] into a single wider store.

This defect occurs in

TMS470 Compiler versions 4.4.17, 4.5.2, 4.4.10.104, 4.6.0, 4.4.15.202

Workaround:
Add "#pragma UNROLL(1)" to the loop with the problem, or compile at -o1
or -o0.

------------------------------------------------------------------------------
FIXED  SDSCM00033671
------------------------------------------------------------------------------

Summary            : Compiler generates incorrect code in some cases 
                     when reading and writing from/to the same array 
                     inside a loop

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

Description:
Under certain very specific circumstances, for a loop that reads from x[0]
(or other fixed index) and writes to x[i] on each iteration, the compiler
may incorrectly generate the write before the read.

This defect occurs in

TMS470 Compiler versions 2.166e - 2.177e, 2.209e, 2.40.beta - 2.71,
4.1.0B1 - 4.1.7, 2.54.02 - 2.54.208, 2.54.03 - 2.54.126, 2.202.03e -
2.202.14e, 4.4.0B1 - 4.4.17, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.104,
4.6.0B1 - 4.6.0, 4.4.15.200 - 4.4.15.203

Workaround:
Slight changes to the code, compiler options, or compiler version may make
the problem appear or disappear.  The most reliable workaround is to
compile at -o1 or -o0;  -o2 may also avoid it.

------------------------------------------------------------------------------
FIXED  SDSCM00033677
------------------------------------------------------------------------------

Summary            : Linker uses default LOAD allocation when a 'run' 
                     address is specified for an initialized section

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

Description:
If a RUN allocation is specified for an initialized section and a LOAD
allocation is not specified for that section the linker will use a
default LOAD allocation which will result different run and load
addresses. This differs from the previous, documented linker behavior
where a single specified RUN or LOAD allocation will cause the section
to only be allocated once.  

This defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.17, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.104, 4.6.0B1 - 4.6.0, 4.4.15.201 - 4.4.15.203

Workaround:
In linker command file specify a LOAD allocation for the affected
section instead of RUN.

------------------------------------------------------------------------------
FIXED  SDSCM00033697
------------------------------------------------------------------------------

Summary            : Linker incorrectly resolves long jumps and does not
                     generate errors or warnings

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

Description:
This bug happens when the customer have a call to an absolute address
and this call needs a long jump patch (trampoline) to reach its branch
destination. Without this fix, the linker simply does not generate this
trampoline. With this fix, we will generate a trampoline assuming the 
caller and callee are in the same machine mode.

We flag a warning for the customer so that they can check to make sure 
that the caller and callee are indeed in the same mode.

This defect occurs in

TMS470 Compiler versions 4.4.16 - 4.4.17, 4.5.0B1 - 4.5.2, 4.6.0B1 -
4.6.0

Workaround:
There is no work around for this bug.

------------------------------------------------------------------------------
FIXED  SDSCM00033770
------------------------------------------------------------------------------

Summary            : Compiler generates incorrect code for a conditional 
                     function call

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

Description:
A read and write involving the same struct field may occur in the wrong
order in situations involving link-time recompilation and a file that
uses pointer-to-struct without defining the struct type.

This defect occurs in

TMS470 Compiler versions 4.1.0B1 - 4.1.7, 4.4.0B1 - 4.4.17, 4.5.0B1 -
4.5.2, 4.4.10.100 - 4.4.10.104, 4.6.0B1 - 4.6.0, 4.4.15.200 -
4.4.15.203

Workaround:
Define the struct types in files which use pointer-to-struct, even if
they don't need to know the details of the struct.  If that isn't
possible, avoid link-time recompilation or use -o1 or -o0.

------------------------------------------------------------------------------
FIXED  SDSCM00033811
------------------------------------------------------------------------------

Summary            : Compiler generates internal error when compiling 
                     C++ include file xtree

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

Description:
When generating profile information using the --gen_profile_info
option a conditional statement of the form   'bool ? a : b' will be
instrumented by rewriting the statement into 'bool ? true_counter++,a : b'.
If 'a' is a function that returns a structure the code generator may not
correctly handle this expression and report an error.  As a workaround
rewrite the conditional expression using if/else.

This defect occurs in

TMS470 Compiler versions 2.41.beta - 2.71, 4.1.0B1 - 4.1.7, 2.54.205 -
2.54.208, 2.54.110 - 2.54.126, 4.4.0B1 - 4.4.17, 4.5.0B1 - 4.5.2,
4.4.10.100 - 4.4.10.104, 4.6.0B1 - 4.6.0, 4.4.15.201 - 4.4.15.204

Workaround:
The codegen is crashing at line 889 in the C++ include file xtree.  It
crashes at this line

return (_Where == end() || _DEBUG_LT_PRED(this->comp,_Keyval,
_Key(_Where._Mynode())) ? end()  _Where);

if that is changed to

if (_Where == end() || _DEBUG_LT_PRED(this->comp,_Keyval,
_Key(_Where._Mynode())))
   return end();
else
   return _Where;

the problem can be worked around.  A version of xtree with this change
is now part of the latest release. To work-around the crash, replace the 
current xtree in the codegen package include directory with a version
thaht includes this change.

------------------------------------------------------------------------------
FIXED  SDSCM00033851
------------------------------------------------------------------------------

Summary            : Array alignment is not optimal in EABI mode.

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

Description:
The compiler would attempt to word align char or short arrays in EABI
mode.  This would occur if the definition of the arrays was included in
the source file.  This word align can improve performance in certain
types of memcpy or strcpy calls which generate load and store multiple
instructions.  However, the word alignment could increase data sizes
through alignment holes between char or short global array variables.

Note, the data sizes would be equivalent to non-EABI COFF data sizes
for the same code.  This change keeps the base type alignment on arrays
as defined by the EABI standard.

------------------------------------------------------------------------------
FIXED  SDSCM00033968
------------------------------------------------------------------------------

Summary            : Compiler fails to generate 16-bit instructions in some
                     cases when it should

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

Description:
Fixed an issue where the codegen was sometimes generating 32-bit
versions of Thumb-2 instructions when a 16-bit instruction was available.

This defect occurs in

TMS470 Compiler versions 4.4.8 - 4.4.17, 4.5.0B1 - 4.5.2, 4.4.10.100 -
4.4.10.104, 4.6.0B1 - 4.6.0, 4.4.15.201 - 4.4.15.204

------------------------------------------------------------------------------
7. Fixed Issues in 4.6.0
------------------------------------------------------------------------------

------------------------------------------------------------------------------
FIXED  SDSCM00020675
------------------------------------------------------------------------------

Summary            : ARM compiler intrinsics not available in thumb mode nor
		     using #pragma CODE_STATE (func,32)

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

Description: 
Many ARM intrinsics are only available in ARM mode. However if a
CODE_STATE 32 pragma is applied to a function containing one of these
intrinsics the compiler will not recognize them as an intrinsic if the
file is compiled in thumb mode.  The compiler has been updated to
address this issue.

Similarly if a function has a CODE_STATE 16 pragma associated with it
the compiler will fail to prevent the use of ARM mode only intrinsics
if the file is compiled in ARM mode. An internal error will have been
emitted. This has also been addressed.

Workaround: 
The functions that require ARM mode compilation have to be placed in a
separate file and compiled in ARM mode..

------------------------------------------------------------------------------
FIXED  SDSCM00024050
------------------------------------------------------------------------------

Summary            : Code size increase in some RTS library functions

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

Description: 
This bug cause code size increase in time related function in RTS 
library, specifically, in asctime() and strftime(). After this fix,
there 
is no excessive inline of string functions used in these two time
related 
functions.
Defect occurs in

C5500 Compiler versions 4.2.0B1 - 4.2.3, 4.3.0B1 - 4.3.4
C6000 Compiler versions 6.1.0B1 - 6.1.11
MSP430 Compiler versions 3.2.0B1 - 3.2.1
TMS470 Compiler versions 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.6.0B1


Workaround: 
There is no work around for this problem.

------------------------------------------------------------------------------
FIXED  SDSCM00028049
------------------------------------------------------------------------------

Summary            : illegal offset generated for vldr instruction

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

Description: 
The VLDR instruction accepts an immediate offset to the base register. 
This offset must be a multiple of four. The compiler has been updated
to 
check that the offset for this instruction must be a multiple of four
Defect occurs in

TMS470 Compiler versions 4.4.0 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100 -
4.4.10.104, 4.6.0B1


Workaround: 
Avoid code which casts char pointers to another type while performing
pointer arithmetic. For example:

char* x;
long long y = *(long long*)(x+1);

------------------------------------------------------------------------------
FIXED  SDSCM00030872
------------------------------------------------------------------------------

Summary            : Type merging fails to merge type sections when all types
		     are not referenced in each file

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

Description: 
DWARF type merging in ELF object files should work correctly for C
files.

Workaround: 
If DWARF type merging is required, use the linker option
--compress_dwarf=on

------------------------------------------------------------------------------
FIXED  SDSCM00032019
------------------------------------------------------------------------------

Summary            : optimizer aborts 
Fixed in           : 4.6.0
Severity           : S2 - Major
Affected Component : C/C++ Compiler (cl)

Description: 
Certain obscure cases of loops may have their end-tests fold to 0
between 
the time loop analysis starts and when it verifies the shape of the 
loop.  In these cases, the optimiser will abort in a sanity check for a

proper loop.  The example in this report is in an internal "grow" 
function in a C++ template class, in a construction that turned out not

to need to grow at all.
Defect occurs in

C6000 Compiler versions 6.1.0B1 - 6.1.10, 7.0.0B1
TMS470 Compiler versions 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.103, 4.6.0B1


Workaround: 
The problem is related to unrolling, and typically one can work around 
those with a "#pragma UNROLL(1)" on the key loop, but here the loop is 
deep inside the <valarray> include file and thus not entirely practical

to modify.

------------------------------------------------------------------------------
FIXED  SDSCM00032116
------------------------------------------------------------------------------

Summary            : Compiler incorrectly reorders subsequent accesses to global
		     variable

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

Description: 
References to external array variables declared with no size, ie,
"extern 
int x[]," may not be properly checked for aliases and their accesses
may 
be made in the wrong order.
Defect occurs in

C2000 Compiler versions 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.5, 5.2.0B1 -
5.2.1
C5400 Compiler versions 4.2.0B1 - 4.2.0
C5500 Compiler versions 4.1.0B1 - 4.1.2, 4.2.0B1 - 4.2.3, 4.3.0B1 -
4.3.3
C6000 Compiler versions 6.1.0B1 - 6.1.10, 7.0.0B1
MSP430 Compiler versions 3.0.0B1 - 3.0.1, 3.1.0B1 - 3.1.0, 3.2.0B1 -
3.2.1
TMS470 Compiler versions 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.103, 4.6.0B1


Workaround: 
Instead of "extern int x[]", use "extern int x[10]" or whatever the 
correct size is.  Or use "extern int *x" which has slightly different 
effects but still avoids the problem.

------------------------------------------------------------------------------
FIXED  SDSCM00032290
------------------------------------------------------------------------------

Summary            : Optimizer hangs (takes a very long time?) when compiling
		     an application w/ -pm option.

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

Description: 
Certain algorithms in the vectorisation pass may have exponential 
behavior when given long blocks of interlinked assignments, appearing
to 
hang the optimiser.
Defect occurs in

C6000 Compiler versions 6.1.0B1 - 6.1.10, 7.0.0B1
TMS470 Compiler versions 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.103, 4.6.0B1


Workaround: 
Compile with -o1 or -o0, break the code into smaller blocks, or use 
--vectorize=off.  In this particular example, using -op2 in conjunction

with -pm was also enough to avoid the problem;	compiling without -pm 
will reduce inlining and also tends to avoid it.

------------------------------------------------------------------------------
FIXED  SDSCM00032325
------------------------------------------------------------------------------

Summary            : Free mismatched memory bug in shell

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

Description: 
Shell could crash with hand-coded assembly source.
Defect occurs in

C2000 Compiler versions 4.1.0B1 - 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 -
5.0.2, 5.1.0B1 - 5.1.5, 5.2.0 - 5.2.1
C5400 Compiler versions 4.1.0B1 - 4.1.1, 4.2.0B1 - 4.2.0
C5500 Compiler versions 2.70 - 2.84, 3.2.0B3 - 3.2.3, 3.3.0 - 3.3.6,
4.0.0B1 - 4.0.2, 4.1.0B1 - 4.1.2, 4.2.0B1 - 4.2.3, 4.3.0B1 - 4.3.3
C6000 Compiler versions 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13,
5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.23, 6.1.0B1 - 6.1.10, 7.0.0B1
MSP430 Compiler versions 2.0.0B1 - 2.0.2, 3.0.0B1 - 3.0.1, 3.1.0B1 -
3.1.0, 3.2.0B1 - 3.2.1
TMS470 Compiler versions 2.41.beta - 2.71, 4.1.0B1 - 4.1.7, 2.54.205 -
2.54.208, 2.54.110 - 2.54.125, 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2,
4.4.10.100 - 4.4.10.103, 4.6.0 - 4.6.0B1


Workaround: 
None.

------------------------------------------------------------------------------
FIXED  SDSCM00032335
------------------------------------------------------------------------------

Summary            : Provide workaround for Cortex-R4 hardware issue #437965

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

Description: 
This change provides a warning if a LDC or STC instruction that uses 
PC/R15 as the base register is encountered in Thumb mode for Cortex-R4
.  
As documented in ARM Cortex-R4 Errata Notice #437965, the Cortex-R4
will 
not perform the required alignment on the value of the PC prior to data

transfer in this case.	The compiler does not generate these 
instructions, but will now issue a warning if they are detected in 
assembly input.

Defect occurs in

TMS470 Compiler versions 4.4.0 - 4.4.16, 4.5.2, 4.4.10.100 -
4.4.10.103, 4.6.0B1


Workaround: 
This silicon bug can be avoided by either
- Only using LDC or STC instructions in ARM state
- Ensuring that all LDC or STC instructions are placed at word-aligned 
addresses.

------------------------------------------------------------------------------
FIXED  SDSCM00032336
------------------------------------------------------------------------------

Summary            : Provide workaround for Cortex-R4 hardware issue #577077

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

Description: 
This change provides a warning if the assembler encounters a Thumb
STREXD 
instruction that uses the same register for both transfer operands.  As

documented in the ARM Cortex-R4 Errata Notice #577077, the Cortex-R4
will 
treat such an instruction as unpredictable and execute it as a NOP. 
The 
compiler does not generate this instruction, but will now issue a
warning 
if it is detected in assembly input compiled for the Cortex-R4.
Defect occurs in

TMS470 Compiler versions 4.4.0 - 4.4.16, 4.5.2, 4.4.10.100 -
4.4.10.103, 4.6.0B1


Workaround: 
None.

------------------------------------------------------------------------------
FIXED  SDSCM00032348
------------------------------------------------------------------------------

Summary            : Linker crashes when trying to write data to an unitialized
		     .debug_info section

Fixed in           : 4.6.0
Severity           : S3 - Minor
Affected Component : ELF Linker

Description: 
The linker creates an internal .debug_info section which contains 
information about linker generated objects (ie. trampolines). This 
section was being created even if all other debug information was
removed 
from the link. The fix is to not create this section if all other 
.debug_info sections were removed

Defect occurs in

C6000 Compiler versions 7.0.0B1
TMS470 Compiler versions 4.6.0B1


Workaround: 
Do not compile the files with --symdebug:none.

------------------------------------------------------------------------------
FIXED  SDSCM00032470
------------------------------------------------------------------------------

Summary            : PC optimizer segmentation fault under eabi while processing
		     huge function with lots of if/else
		     statements and huge structures

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

Description: 
On Windows only, compiling a very large function with many references
to 
global, aliased, or union variables may cause an optimiser crash due to
a 
stack overflow.
Defect occurs in

C2000 Compiler versions 4.1.0B1 - 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 -
5.0.2, 5.1.0B1 - 5.1.5, 5.2.0B1 - 5.2.1
C5400 Compiler versions 4.1.0B1 - 4.1.1, 4.2.0B1 - 4.2.0
C5500 Compiler versions 3.2.0B3 - 3.2.3, 3.3.0 - 3.3.6, 4.0.0B1 -
4.0.2, 4.1.0B1 - 4.1.2, 4.2.0B1 - 4.2.3, 4.3.0B1 - 4.3.3
C6000 Compiler versions 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 -
5.3.0, 6.0.1B1 - 6.0.23, 6.1.0B1 - 6.1.10, 7.0.0B1
MSP430 Compiler versions 2.0.0B1 - 2.0.2, 3.0.0B1 - 3.0.1, 3.1.0B1 -
3.1.0, 3.2.0B1 - 3.2.1
TMS470 Compiler versions 4.1.0B1 - 4.1.7, 4.4.0B1 - 4.4.16, 4.5.0B1 -
4.5.2, 4.4.10.100 - 4.4.10.103, 4.6.0B1


Workaround: 
Use smaller functions, fewer globals, fewer unions, and take the
address 
of fewer variables.  Or increase the allowed stack size, if one can do 
that on Windows.

------------------------------------------------------------------------------
FIXED  SDSCM00032509
------------------------------------------------------------------------------

Summary            : ARM floating point addition and subtraction results do not
		     round correctly

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

Description: 
The rounding mode used in the RTS functions were round to nearest, ties go
to infinity. An example of this would be rounding .5 to 1. These routines
should use round to even, which is basically round to nearest where ties go
to the nearest even number. So in this case .5 would round to 0.

Workaround: 


------------------------------------------------------------------------------
FIXED  SDSCM00032539
------------------------------------------------------------------------------

Summary            : ARM intrinsic causes warning

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

Description: 
This change extends the fix for SDSCM00030597 to include other 
deprecated forms of the MSR instruction.  The MSR [CSA]PSR_<flags>, Rn 
instruction now requires proper flag specifications on the PSR operand.
 
Previously, the specifications "_flg" and "_all" were accepted.  The 
current specification forms, "_f" and "_cf" respectively, should now be

used.  Old forms of this instruction will result in a warning if in ARM

mode, and an error if in Thumb mode. 

There is a minor compatibility impact in that assembly code generated
by 
previous compiler versions may contain the deprecated syntax, but this 
would come from ARM intrinsics and therefore result in a warning, not a

compile error.
Defect occurs in

TMS470 Compiler versions 4.4.16, 4.5.2, 4.6.0B1


Workaround: 
None.

------------------------------------------------------------------------------
FIXED  SDSCM00032541
------------------------------------------------------------------------------

Summary            : Parser does not remove initialization guard variable for
		     unused extern inline function

Fixed in           : 4.6.0
Severity           : S2 - Major
Affected Component : Parser

Description: 
When using --abi=eabi, due to a parser bug, the assembler generates an
internal error. This happens when there is a dynamically initialized
static variable in an inline function and this function is not called.

  struct A {
    A(int) {}
  };
  inline void f(void) {
    static A a = 5; 
  }

If the above is included from a header file but there is no call to the
function f() it results in asm internal error.


Workaround: 
Make an explicit call to the inline function.

------------------------------------------------------------------------------
FIXED  SDSCM00032672
------------------------------------------------------------------------------

Summary            : Highly inefficient use of stack space

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

Description: 
The compiler may waste stack space in two ways.  If a struct variable
is 
defined locally, the optimiser may attempt to break it into separate 
temporary variables, one per field, because that often allows for
better 
results.  However, if the struct's address is taken, it can't be broken

up that way.  The problem is that the compiler has already created the 
new temporary symbols, though they won't be used, and they will take up

space on the stack.

The other way is that if separate scopes that define aggregate
variables 
are ultimately defined within only one scope within the function scope,

the variables won't be shared on the stack even though they could be.  
There was a mistake in the test for whether sharing was worthwhile;  it

insisted that there be at least two scopes immediately within the 
function scope.
Defect occurs in

C2000 Compiler versions 3.08 - 3.13, 4.1.0B1 - 4.1.4, 4.3.0B1 - 4.3.0,
5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.5, 5.2.0B1 - 5.2.1
C5400 Compiler versions 3.83, 4.1.0B1 - 4.1.1, 4.2.0B1 - 4.2.0
C5500 Compiler versions 2.70 - 2.84, 3.2.0B3 - 3.2.3, 3.3.0 - 3.3.6,
4.0.0B1 - 4.0.2, 4.1.0B1 - 4.1.2, 4.2.0B1 - 4.2.3, 4.3.0B1 - 4.3.3
C6000 Compiler versions 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13,
5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.23, 6.1.0B1 - 6.1.10, 7.0.0B1
MSP430 Compiler versions 2.0.0B1 - 2.0.2, 3.0.0B1 - 3.0.1, 3.1.0B1 -
3.1.0, 3.2.0B1 - 3.2.1
TMS470 Compiler versions 2.209e, 2.40.beta - 2.71, 4.1.0B1 - 4.1.7,
2.54.02 - 2.54.208, 2.54.03 - 2.54.125, 2.202.03e - 2.202.13e, 4.4.0B1
- 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.104, 4.6.0B1


Workaround: 
None, except to share the stack variables by hand.

------------------------------------------------------------------------------
FIXED  SDSCM00032744
------------------------------------------------------------------------------

Summary            : optimizer crash with options -mv7a8 --neon -mf5 -o3

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

Description: 
A loop in which two pairs of two adjacent array elements each are all 
written may cause an optimiser abort if it can combine the pairs into a

larger single write.  Combining the first pair leaves an inconsistent 
state that combining the second pair trips over.
Defect occurs in

C6000 Compiler versions 6.1.0B1 - 6.1.10, 7.0.0B1
TMS470 Compiler versions 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.104, 4.6.0B1


Workaround: 
Avoid loops where four adjacent array elements are written with literal

constant indices.  In this test case, instead of using sum[0], sum[1], 
etc, within the loop, use scalars like sum0, sum1, etc, and write sum0
to 
sum[0] after the loop.

------------------------------------------------------------------------------
FIXED  SDSCM00032746
------------------------------------------------------------------------------

Summary            : Using designated initializers on unions causes the parser
		     to crash

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

Description: 
The compiler does not support this GCC extension, but instead of
issuing an error, the compiler accepted the syntax and crashed in a later
phase. The compiler will now issue an error if designated initializers are
used for unions. 

Defect occurs in
C2000 Compiler versions 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.5, 5.2.0B1 -
5.2.2
C5400 Compiler versions 4.2.0B1 - 4.2.0
C5500 Compiler versions 4.0.0B1 - 4.0.2, 4.1.0B1 - 4.1.2, 4.2.0B1 -
4.2.3, 4.3.0B1 - 4.3.4
C6000 Compiler versions 6.1.0B1 - 6.1.11, 7.0.0B1
MSP430 Compiler versions 2.0.0B1 - 2.0.2, 3.0.0B1 - 3.0.1, 3.1.0B1 -
3.1.0, 3.2.0B1 - 3.2.1
TMS470 Compiler versions 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.104, 4.6.0B1, 4.4.15.201 - 4.4.15.202


Workaround: 
Remove uses of designated initializers for unions.

------------------------------------------------------------------------------
FIXED  SDSCM00032747
------------------------------------------------------------------------------

Summary            : optimizer crash

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

Description: 
A reduction loop like

    for (j = 0; j < 8; j++)
      sum += x[j]

may cause an optimiser abort when x[] is an array of char and the loop
is 
compiled for ARM Neon with -mf.  This combination tries to unroll the 
loop 8X and runs into an internal inconsistency that causes the abort.
Defect occurs in

C6000 Compiler versions 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13,
5.3.0B1 - 5.3.0
TMS470 Compiler versions 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.104, 4.6.0B1


Workaround: 
Add "#pragma UNROLL(1)" to the loop to inhibit the vectorisation that 
leads to the problem.  In this particular test case, UNROLL(2) and 
UNROLL(4) also work, and it also works to add the pragma to the other 
inner loop instead.

------------------------------------------------------------------------------
FIXED  SDSCM00032749
------------------------------------------------------------------------------

Summary            : optimizer terminated abnormally

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

Description: 
Certain rare situations may lead to more than one internal definition 
being applicable to an operator, at a point when only one is allowed, 
causing an optimiser abort.  It's hard to be more specific, because
this 
report has no source code for its test case;  it appears to involve an 
expression like "0x1234u - _mpyu(x,y)" for C64+, and two subtract 
instructions might apply.
Defect occurs in

C6000 Compiler versions 6.1.0B1 - 6.1.10, 7.0.0B1
TMS470 Compiler versions 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.104, 4.6.0B1


Workaround: 
Without source, it's hard to give a good workaround.  Perhaps the 
unsigned constant could be made signed, and then only one subtract
would 
apply.	Compiling at -o1 instead of -o2 would also work, but has a 
performance cost.

------------------------------------------------------------------------------
FIXED  SDSCM00032856
------------------------------------------------------------------------------

Summary            : application code runtime decrease of about 2% between 4.4.8
		     and 4.4.15

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

Description: 
Code using many accesses to small bitfields can be larger and slower
than 
it was in earlier releases, because the struct accesses use the
smallest 
valid type rather than a larger type that allows more combination of 
adjacent operations.  The patch for this problem will try to use the 
declared type of the bitfield instead, which is usually int.
Defect occurs in

MSP430 Compiler versions 3.2.0B1 - 3.2.1
TMS470 Compiler versions 4.4.15 - 4.4.16, 4.5.2, 4.6.0B1, 4.4.15.200


Workaround: 
Making bitfield accesses in the same order as the fields can allow more

combination, but won't relieve all the code growth.

------------------------------------------------------------------------------
FIXED  SDSCM00032876
------------------------------------------------------------------------------

Summary            : optimizer out of memory error

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

Description: 
A loop containing many expressions like "x += x + y", repeatedly using 
the same variable, where "y" is a larger expression involving indexed 
array references, may cause the optimiser to run out of memory and
abort.

The problem is that the many assignments updating the same variable can

all be combined into a single large expression, made even larger by the

effective doubling of the uses with each statement.  The memory 
references afford the possibility of vectorisation.  The "+" operator
has 
many possible vector expansions.  As a result, there are many many 
combinations to try, and the optimiser does not limit itself.
Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.6.0B1


Workaround: 
Reduce the size of the loop by avoiding hand-unrolling.  Avoid 
expressions like "x += x + y" which effectively double the instances of
x 
in each successive statement;  try "x = 2*x + y" instead.

------------------------------------------------------------------------------
FIXED  SDSCM00032924
------------------------------------------------------------------------------

Summary            : -mh option does not improve performance with ELF as
		     compared to COFF

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

Description: 
When compiling for ELF (ie, --abi=eabi), performance may be adversely 
affected when a loop writes to a local char array (for example, in an 
inlined call to strcpy()) and a call to malloc() is assigned to char*
in 
the same function.  While a heap allocation and a stack allocation
should 
be easily disambiguated, the ELF name for malloc() isn't recognised
like 
it should be.
Defect occurs in

C6000 Compiler versions 7.0.0B1
TMS470 Compiler versions 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.104, 4.6.0B1


Workaround: 
Add "restrict" to the pointer affected by the problem;	the .nfo file 
may contain advice indicating which one.

------------------------------------------------------------------------------
FIXED  SDSCM00032979
------------------------------------------------------------------------------

Summary            : If interrupt occurs during function return where a
		     structure from stack is written back
		     memory; structure gets overwritten

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

Description: 
The compiler may not generate interrupt safe code in the epilog of 
functions that return a structure.  If the structure value to be
returned 
is defined locally then, in some cases, the code that copies that 
structure from the stack to the destination specified by the caller may

be scheduled after the instruction that deallocates the stack frame. 
If 
an interrupt occurs after the stack frame is deallocated (the stack 
pointer updated) but before the structure is copied off the stack that 
structure value may be corrupted by an interrupt if the architecture
uses 
the same stack as the compiler to perform the interrupt context
switches.
Defect occurs in

TMS470 Compiler versions 4.4.15 - 4.4.16, 4.6.0B1, 4.4.15.200


Workaround: 
Manipulate source code or compile options to avoid problematic
sequence.

------------------------------------------------------------------------------
FIXED  SDSCM00033179
------------------------------------------------------------------------------

Summary            : The compiler uses incorrect calling convention for EABI
		     routines, converting between long long
		     and float types

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

Description: 
This bug only affects code which performs this conversion and 
a.) is compiled by another vendor and linked with a TI RTS or b.) is 
compiled with the TI compiler and linked with another vendor's RTS. If 
these conditions apply to your code, it is unsafe to perform those
tasks with versions of the TI tools without this fix. 
Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.16, 4.5.0B1 - 4.5.2, 4.6.0B1


Workaround: 
Avoid conversions between 64-bit integer types and floats/doubles when 
VFP is enabled.

------------------------------------------------------------------------------
8. Fixed Issues in 4.6.0B1
------------------------------------------------------------------------------

------------------------------------------------------------------------------
FIXED  SDSCM00017184
------------------------------------------------------------------------------

Summary            : Assembler generates a relocation type for Thumb2 BL
		     instructions that does not allow linker to convert it to 
		     BLX

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

------------------------------------------------------------------------------
FIXED  SDSCM00020785
------------------------------------------------------------------------------

Summary            : alchemy link ignores #pragma CODE_STATE (func,32) function
		     designation

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

------------------------------------------------------------------------------
FIXED  SDSCM00023936
------------------------------------------------------------------------------

Summary            : setjmp/longjmp defect

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

Description: 
If an auto variable is declared with both the 'register' and 'volatile'
qualifier the code generator will not treat the variable as volatile if
optimization is not used.  

------------------------------------------------------------------------------
FIXED  SDSCM00024784
------------------------------------------------------------------------------

Summary            : C++ file level variables inside a namespace mistakenly
		     disallowed from using DATA_SECTION pragma

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

Description: 
File level pragmas have been updated to operate on symbols declared 
within namespaces.

------------------------------------------------------------------------------
FIXED  SDSCM00025898
------------------------------------------------------------------------------

Summary            : Extremely Long Link Time

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

------------------------------------------------------------------------------
FIXED  SDSCM00026161
------------------------------------------------------------------------------

Summary            : -pr option predefines __GNUC__

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

Description: 
The relaxed ANSI mode (-pr) was enabling GNU extensions in error.  The
--gcc option should be used to enable GNU extensions.

------------------------------------------------------------------------------
FIXED  SDSCM00029852
------------------------------------------------------------------------------

Summary            : Indeterminate ordering of output sections in the linker

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

------------------------------------------------------------------------------
FIXED  SDSCM00030165
------------------------------------------------------------------------------

Summary            : Linker allows erroneous combination of -s and -r

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

------------------------------------------------------------------------------
FIXED  SDSCM00030216
------------------------------------------------------------------------------

Summary            : Arm linker internal error during elf mode alchemy link

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

Description: 
The linker tried to find the icode section by the name of ".icode", but
in EABI the name is "__TI_ICODE".  The linker now looks for the correct
section name.

------------------------------------------------------------------------------
FIXED  SDSCM00030403
------------------------------------------------------------------------------

Summary            : Need to allow '$' symbol in TMS470 EABI variable names

Fixed in           : 4.6.0B1
Severity           : S2 - Major
Affected Component : Shell

Description: 
With the 4.6.0A alpha tools only, support for variable names with the
'$' symbol was removed, except for gcc extension mode.  This support has
been re-enabled for EABI mode.

------------------------------------------------------------------------------
FIXED  SDSCM00030499
------------------------------------------------------------------------------

Summary            : TMS470 unnecessary veneers getting generated for Cortex-R4

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

------------------------------------------------------------------------------
FIXED  SDSCM00030598
------------------------------------------------------------------------------

Summary            : Copy table output sections are not supported

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

------------------------------------------------------------------------------
FIXED  SDSCM00031217
------------------------------------------------------------------------------

Summary            : macro subsitution failure 

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

Description: 
If a label is used an argument to a macro invocation and the macro 
definition has parameters with the same name the assembler may 
incorrectly do substitution symbol expansion if the parameter is mapped
to another argument.  

------------------------------------------------------------------------------
FIXED  SDSCM00031530
------------------------------------------------------------------------------

Summary            : --import=foo generates incorrect warning when
		     --forced_static_binding=off

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

------------------------------------------------------------------------------
FIXED  SDSCM00031968
------------------------------------------------------------------------------

Summary            : sometimes Build attribute's don't care value is not handled
		     correctly by the linker.

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


------------------------------------------------------------------------------
9. Known Issues
------------------------------------------------------------------------------

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00008203
------------------------------------------------------------------------------

Summary            : Assembler crash with wrong syntax in thumb asm code
Affected Component : Assembler

Description: 
The assembler will crash with the following wrong thumb syntax

BLT 0x8c

the correct syntax is 

BLT #0x8c

but the assembler shouldn't crash.

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

Summary            : Compilers on PC will not work without TMP set
Affected Component : C/C++ Compiler
                                                                                
Description:
When compiling on the PC, the code generator cannot find the icode
file produced by the parser if the environment variable TMP is not
set.  If TMP is set, then all appears well.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00008251
------------------------------------------------------------------------------

Summary            : Printf format '%#04x' fills zeros into wrong location
Affected Component : Code Generator

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00008276
------------------------------------------------------------------------------

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

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00008340
------------------------------------------------------------------------------

Summary            : directory name with '(' character causes linker error
Affected Component : Shell

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

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

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

If you change the code to

 .space a
b
a .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 C/C++
		     Compiler
Affected Component : Parser

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00008930
------------------------------------------------------------------------------

Summary            : C++ allows enumerators larger than 'int' 
Affected Component : Parser

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00010718
------------------------------------------------------------------------------

Summary            : bad input causes ARM assembler to crash
Affected Component : Assembler

Description: 
Assembly file with bad input causes the assembler to crash

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00012798
------------------------------------------------------------------------------

Summary            : Linker map file does not print "beta" or "alpha" with
		     version number
Affected Component : Linker

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00013456
------------------------------------------------------------------------------

Summary            : fgets in _IONBF mode does not respect size limit
Affected Component : Runtime Support Libraries (RTS)
                                                                                
Description:
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.

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

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00016145
------------------------------------------------------------------------------

Summary            : Incorrect padding of wider-than-int bit-field initializers
Affected Component : Code Generator

Description: 
In EABI mode, where 64-bit bit-field container types are allowed, the
codegen does not properly pad bit-fields wider than 32 bits.  This is
particularly noticable when the bit-field is preceeded by a one-bit
field.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00016886
------------------------------------------------------------------------------

Summary            : Thumb interrupt handlers should begin in ARM mode
Affected Component : Code Generator

Description:
Thumb interrupt functions should begin in ARM mode because interrupt
functions are *only* entered via the interrupt handler table, which
begins in ARM mode.  (Except for M3, and so this doesn't apply for that
architecture.)

Currently, the interrupt function will begin in thumb mode and we will
generate a veneer for it with a different name.  So a user must use the
veneer name in the interrupt table.  However, because the function is
marked as an interrupt handler in the source, he should be using the
actual function name.

Thus, in our current implementation, the veneer should be given the
name of the function and some other non-global label should be used for
the thumb entry point into the function.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00016909
------------------------------------------------------------------------------

Summary            : Assembler fails when an unaligned .field is used
Affected Component : Assembler

Description: 
A .field directive can cause the assembler to crash if it is not
preceded by a .align directive.  This is due to how fields are placed
and the interaction with jump expansion.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00016910
------------------------------------------------------------------------------

Summary            : Assembler doesnt restrict D register usage for VFP/NEON
Affected Component : Assembler

Description: 
The assembler does not make sure that only the first 16 D registers are
used for VFPv2 and VFPv3D16.  It also allows D regs in a list that
expects S registers and allows more than 16 registers in a FLDM/FSTM
register list.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00017607
------------------------------------------------------------------------------

Summary            : The -ppd switch does not work with .cdecls or .include 
                     directive in assembly source files
Affected Component : C/C++ Compiler

Description: 
Logically, if a file is included into another file then that included
file becomes a dependency for the one that includes it. Then, if -ppd
option is used in compiler invocation it shall generate proper
dependency information. Compiler does this for #include in C files but
it does not happen for .cdecls in assembly files.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00018347
------------------------------------------------------------------------------

Summary            : No linker warning when input section alignment overrides
		     user specified alignment
Affected Component : Linker

Description: 
The older linker would generate this error if an input section
alignment was greater than a user's specified alignment

>> warning Output section ".bss"'s user specified run alignment of 4 is
	    overridden to be 2048 by the required alignment of the
            input section in "file.obj"
 
The new linker does not generate any warning.  

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

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00019815
------------------------------------------------------------------------------

Summary            : Compiler should not generate any error output when using
		     -qq and -pdf
Affected Component : C/C++ Compiler

Description: 
Compiler sends error messages to STDOUT with -qq and -pdf.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00024879
------------------------------------------------------------------------------

Summary            : SIGSEGV on invalid mnemonic
Affected Component : Assembler

Description: 
asm470 crashes with SIGSEGV on invalid mnemonic starting "blea"

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00024957
------------------------------------------------------------------------------

Summary            : OFD dump of aeabi build attribute gives incorrect
		     description
Affected Component : Object File Dump Utility (ofd)

Description: 
ofd470 dumps the build attributes of an object file with the
description of the build attribute's value following in parenthesis. 
However, the description for the tag Tag_ARM_ISA_use is incorrect.  It
should not be "(Producer Major Version + 1)"

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00029483
------------------------------------------------------------------------------

Summary            : asm470 crash on bad asm instruction
Affected Component : Disassembler (dis)

Description: 
The assember will crash with MOV R0 #0.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00029958
------------------------------------------------------------------------------

Summary            : Linker generates internal error and aborts when linking
                     EABI objects and libraries
Affected Component : ELF Linker

Description:
Linker generates internal error and aborts with following message when
linking EABI objects and libraries

fatal error #10163 internal error at "table.c", line 972
(__TI_cinit_table, ".data")

Instead of generating an internal error and aborting, the linker should 
enforce the restriction that in ELF, .cinit cannot be grouped with other
data.

Workaround:

Avoid grouping .cinit section with other data in the linker command file
when linking ELF object files together.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00030125
------------------------------------------------------------------------------

Summary            : Linker generates confusing error message and fails
Affected Component : C/C++ Compiler (cl)

Description: 
If a linker command file configures MEMORY for a particular address,
and then uses specific placement for an input SECTION at an address
that precedes the configured address, the following messages are issued

"lnk_specAddrMakesDefaultOverlaps.cmd", line 13 warning #10096-D
specified
   address lies outside memory map
error #10264 DEFAULT memory range overlaps existing memory range MEM
error #10010 errors encountered during linking; "z.out" not built

>> Compilation failure

The first warning indicates that the address used for specific
placement is not part of the MEMORY specified in the command file,
which is fine.	The new linker then attempts to create a DEFAULT
section to contain the input that was specifically placed.  This
DEFAULT section is created such that it begins at the address given for
specific placement and extends to the end of memory.  Since MEMORY
includes an output section that begins after the specific placement
address, the creation fails.  This causes the display of the message
involving the DEFAULT memory range, which the user knows nothing about.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00031818
------------------------------------------------------------------------------

Summary            : Assembler does not accept optional 2 register format for
		     instructions which accept 3 registers
Affected Component : C/C++ Compiler (cl)

Description: 
In UAL the following are identical

ADD R0, R0, R1
ADD R0, R1

We do not accept this format for instructions


------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00033102
------------------------------------------------------------------------------

Summary            : Test fails with RVDS 4.0 tools
Affected Component : C/C++ Compiler (cl)

Description: 
Test fails when using ARM Ltd RVDS 4.0.  This test
is an interoperability test to make sure our compiler generates object
files that are compatibile with ARM Ltd. EABI.	 This may be a bug in
our tools, or a bug in ARM Ltd.'s tools.  The test case builds without
error and runs to completion, but prints the message "Failed".
When this issue is fixed, modify bugslayer/targmap.pm to use RVDS 4.0

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00033742
------------------------------------------------------------------------------

Summary            : Need interrupt intrinsics for Cortex-M3
Affected Component : C/C++ Compiler (cl)

Description:
The interrupt intrinsics _disable_interrupts, _enable_interrupts, and
_restore_interrupts are only supported when building for ARM mode.
That is fine for all devices except Cortex-M3, which only supports
Thumb mode.  There must be Cortex-M3 instructions for disabling and
enabling interrupts.  Please map these intrinsics to those
instructions.

See this external forum thread for more motivation
http//e2e.ti.com/forums/t/10228.aspx .

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00034017
------------------------------------------------------------------------------

Summary            : .debug_line information programs empty in some cases
Affected Component : C/C++ Compiler (cl)

Description:
A customer is finding that, in their build environment, line
information is missing for certain functions.  

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00034636
------------------------------------------------------------------------------

Summary            : cannot link / interop TI TMS470 M3 applications w/ other
		     vendor libraries
Affected Component : C/C++ Compiler (cl)

Description: 
Version 4.6.1 of the TMS470 CGT uses a wchar_t type with sizeof(wchar_t) == 2. 
The EABI specification allows for supporting wchar_t with size of 2 or 4, but 
the TMS470 CGT does not provide a way to configure the size of the wchar_t type.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00034802
------------------------------------------------------------------------------

Summary            : Clearly flag and disable beta VFPv3 UAL instructions
Affected Component : Assembler

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00036087
------------------------------------------------------------------------------

Summary            : Code  size increase with change in cg tools
Affected Component : C/C++ Compiler (cl)

Description: 
Code size increase by selection of ELF format (over COFF format). 

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00037169
------------------------------------------------------------------------------

Summary            : C Runtime function localtime() generates incorrect results
Affected Component : Runtime Support Libraries (RTS)

Description: 

The function localtime() appears to contain two bugs:

The value of the tm_year field returned is relative to 1970 when the
ISO C definition of the function requires that it be relative to 1900
(i.e. different from the Epoch start date used to define time_t). This
year should be returned as 110 but is actually returned as 40. 
The tm_wday field is apparently incorrectly calculated. Passing in a
time_t representing today (Monday), the function returns 5 (Friday) in
this field. 
 
------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00037170
------------------------------------------------------------------------------

Summary            : Embed does not handle cross-filesystem rename correctly
Affected Component : Embed Utility

Description: 
embed470 makes a call to rename() across filesystems without having a
fallback method (i.e. file copy).  If the /tmp directory is on a
different filesystem, the rename will fail, and embed470 will fail.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00038834
------------------------------------------------------------------------------

Summary            : unsigned compare macro problems with Arm 4.6.x codegen
Affected Component : C/C++ Compiler (cl)

Description: 
The compiler is not consistently handling the part of the standard that is 
implementation defined.  It isn't safe to assume that the following would 
always evaluate to false:

    unsigned int a;
    unsigned int b;

    a = 0x7FFFFFF0;
    b = 0x80000007;

    if (((int)(a - b)) > 0)
        printf("true\n");
    else
        printf("false\n");

Since a - b is an unsigned int value greater than INT_MAX, this conversion is 
implementation defined.  However, the TI compiler rule is this should be a 
bit-by-bit copy.  For the arm tools, this appears broken only when the compiler 
is used without optimization, or at level -o0.  

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00038860
------------------------------------------------------------------------------

Summary            : Handling of NOLOAD sections is inconsistent between ELF and
		     COFF
Affected Component : Linker

Description: 
A NOLOAD section in COFF is not present in the output file.  A NOLOAD
section in ELF is present in the object file. 

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00039315
------------------------------------------------------------------------------

Summary            : GCC designated initializer extension causes an internal
		     error
Affected Component : C/C++ Compiler (cl)

Description: 
Compiling the following with "cl470 --gcc -c foo.c"
 
struct foo {
     int a;
};
struct foo *foo = (struct foo[]) { {.a = 0} };
 
gives "internal error".

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00039811
------------------------------------------------------------------------------

Summary            : blx instructions generates error "offset out of range"
Affected Component : Assembler

Description: 
If used with a .global reference the blx thumb instruction generates
this error

"boardAsm.asm", ERROR!	 at line 48 [E0200] Offset out of range, must be
     [-4194304,4194303]
     blx boardHWStartup

This appears to be because the assembler is trying to use the 16bit
version of the instruction.  A workaround is to force the 32bit
version by using blx.w


------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00039965
------------------------------------------------------------------------------

Summary            : -b to be documented in TMS470 UG
Affected Component : Hex Converter (hex)

Description: 
refer forum thread for more details.
http//e2e.ti.com/support/development_tools/compiler/int-compiler/f/85/p
/102624/374448.aspx#374448
