ARM C/C++ CODE GENERATION TOOLS
4.9.9
September 2013
Defect History

------------------------------------------------------------------------------
Table of Contents
------------------------------------------------------------------------------
1.  4.9.9 Fixed Issues
2.  4.9.8 Fixed Issues
3.  4.9.7 Fixed Issues
4.  4.9.6 Fixed Issues
5.  4.9.5 Fixed Issues
6.  4.9.4 Fixed Issues
7.  4.9.3 Fixed Issues
8.  4.9.2 Fixed Issues
9.  4.9.1 Fixed Issues
10. Current Known Issues


------------------------------------------------------------------------------
1. 4.9.9 Fixed Issues
------------------------------------------------------------------------------

------------------------------------------------------------------------------
FIXED  SDSCM00042344
------------------------------------------------------------------------------

Summary            : Compiler generates internal error illegal initialization or
		     segmentation fault

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

Description: 
Compiler sometimes generates internal error illegal initialization or
segmentation fault when using gcc extension nested designed
initializers.

Workaround: 
The seg fault can be worked around if the nested designated initializer
is removed

static struct cfg   config[] =
{
    // the first definition makes the segmentation fault. Comment it
and everything is fine.
    { .module_id    = MODULE_1,
      .param_length = sizeof(struct module_1_params),
      .param	    = (struct module_1_params []){{1}} /* remove this
designated initializer */
    },

    { .module_id    = MODULE_2,
      .param_length = 5,
      .param	    = (int[]){0,1,2,3,4}
    },

    { .module_id    = MODULE_3,
      .param_length = 2,
      .param	    = (int[]){0,1}
    }

};

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

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

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

Description: 
When the # and 0 flags are both used with the x conversion specifier,
any extra 0 characters added to fill up the precision should be added after
the 0x prefix, but the TI library added them before the 0x prefix.

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.120, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 5.0.0B1 -
5.0.6, 5.1.0B1 - 5.1.1


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

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

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

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

Description: 
The bug could happen when partial link is used. Also one or more files 
partially linked are compailed with optimization. The optimizer 
recognized some function as alias function. The paritial does not
handle alias function correctly.

Defect occurs in

TMS470 Compiler versions 4.9.0B1 - 4.9.8, 5.1.0B1


Workaround: 
There is no work around for this bug.

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

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

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

Description: 
There can be duplicate section names in an object file.  When
converting such a file, the hex converter will emit a warning and fail
to convert the section.  For this test case, it is sufficient to have
the hex converter ignore zero-length sections.	Handling duplicate
section names, neither of which are empty, will require some redesign,
and will be pursued as a separate effort.  This defect report has been
re-purposed as the more targeted fix of ignoring zero-length sections.
See SDSCM00046936 for the ongoing work to handle duplicate section
names for non-empty sections.

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.119, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 5.0.0B1 -
5.0.4, 5.1.0B1


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

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

Summary            : ELF section header table not guaranteed to be aligned

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

Description: 
I conclude that the linker is generating something wrong when creating 
relocatable output that gets corrected when it later generates
executable 
output. A further observation after linking the relocatable linker 
output to form an executable, I note that the section headers are 
misaligned (at offset 0xaca from the start of the file). 
This appears to break the alignment rule from
http//www.sco.com/developers/gabi/2003-12-17/ch4.intro.html#file_format

"All data structures that the object file format defines follow the 
``natural'' size and alignment guidelines for the relevant class. If 
necessary, data structures contain explicit padding to ensure 8-byte 
alignment for 8-byte objects, 4-byte alignment for 4-byte objects, to 
force structure sizes to a multiple of 4 or 8, and so forth. Data also 
have suitable alignment from the beginning of the file. Thus, for 
example, a structure containing an Elf32_Addr member will be aligned on
a 
4-byte boundary within the file. " Section headers contain Elf32_Addr 
members, and so should be aligned on a 4-byte boundary (which 0xaca 
isn't). It appears that the compiler is failing to pad the size of the 
string table to ensure the alignment of the following areas. You can
see that the alignment of the section headers depends on the size of the 
string table by changing the function name to 'main2'. This generates
an output file where the section header offset is 534. The misaligned 
section headers lead to a CCS crash (SDSCM00046176).

Defect occurs in

TMS470 Compiler versions 4.9.0 - 4.9.8, 5.0.0B1 - 5.0.4, 5.1.0B2 -
5.1.0B1


Workaround: 
None.

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

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

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

Description: 
With the following program

#pragma DATA_SECTION(array, 4)
int array[100];

Observe that the alignment of array is 32, should be 64.
The DATA_ALIGN pragma should not cause an array to have an
alignment that is less than the default array alignment.  The
DATA_ALIGN pragma is ignored if it attempts to do so.


Workaround: 
Use the DATA_ALIGN pragma with minimum default array alignment value

------------------------------------------------------------------------------
FIXED  SDSCM00046427
------------------------------------------------------------------------------

Summary            : MISRA-C Compliance of RTS Library/Headers

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

Description: 
This update does not provide complete MISRA compliance for the entire 
RTS.  Work will continue towards that goal, but full compliance can not
be guaranteed.	This update does eliminate some warnings from RTS files
to begin the process.  

Defect occurs in

TMS470 Compiler versions 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8,
4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.5, 5.1.0B1


Workaround: 
The #pragma CHECK_MISRA("none") can be used to disable MISRA checking 
prior to including standard header files.  The #pragma
RESET_MISRA("all") will re-enable MISRA checking. 

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

Summary            : Instructions are placed in the wrong order

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

Description: 
In rare cases, incorrect analysis by the compiler may indicate that two
memory or stack accesses are unrelated when they actually refer to the 
same object.  If this occurs, the compiler may schedule an access 
incorrectly.

Defect occurs in

TMS470 Compiler versions 4.9.0B1 - 4.9.8, 5.0.0B1 - 5.0.4, 5.1.0B1


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


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

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

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

Description: 
stdin, stdout, and stderr are macros involving the identifier
std_ftable.  As a macro, the namespace is not specified as you would
for a type or variable (stdsize_t).  When cstdio is included, these
macros are defined and should be usable without a using declaration
putting std_ftable in the global namespace.

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.119, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 5.0.0B1 -
5.0.4, 5.1.0B1


Workaround: 
Include stdio.h instead of cstdio

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

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

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

Description: 
Using an invalid option with valid hex command file causes a
segmentation fault.

Defect occurs in

TMS470 Compiler versions 4.6.0B1 - 4.6.6, 4.7.0B1 - 4.7.1, 4.8.0B1,
4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.4, 5.1.0B1


Workaround: 
Fix or eliminate the invalid option.

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

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

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

Description: 
The definition of isnan and isinf in the header file math.h eventually 
refers to library functions, and in C++ needs to refer to these
functions in a namespace.  The user should be able to use isnan and isinfo
without refering to the std namespace.

Defect occurs in

TMS470 Compiler versions 4.8.0B1, 4.9.0B1 - 4.9.8, 5.0.0B1 - 5.0.4,
5.1.0B1


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

------------------------------------------------------------------------------
FIXED  SDSCM00047236
------------------------------------------------------------------------------

Summary            : The __sqrt and __sqrtf intrinsics do not work in C++

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

Description: 
The bug occurs because the intrinsics are defined in the C++ std 
namespace. 

Defect occurs in

TMS470 Compiler versions 4.9.0B1 - 4.9.8, 5.0.0B1 - 5.0.4


Workaround: 
The workaround is to use std__sqrt() and std__sqrtf() to invoke the 
intrinsics. Please note that once the bug is fixed this syntax will no 
longer be valid and you will have to use sqrt() and sqrtf() without the

namespace prefix.

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

Summary            : different binaries after compilation

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

Description: 
When address-space layout randomization is used by the OS, as is
usually the case for modern Windows and Linux versions, compiler output may be 
different once in a while on the same input.  It isn't predictable;  in
the given test case, usually only a handful of iterations are needed 
before a difference appears, but sometimes it takes a couple dozen.

Defect occurs in

TMS470 Compiler versions 4.9.0B1 - 4.9.8, 4.10.0B1, 5.0.0B1 - 5.0.5,
5.1.0B1


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

------------------------------------------------------------------------------
FIXED  SDSCM00047302
------------------------------------------------------------------------------

Summary            : Sequence of ops all to same location smaller than int may
		     compile incorrectly

Fixed in           : 4.9.9
Severity           : S2 - Major
Affected Component : Assembly Optimizer

Description: 
A sequence of assignments to a memory location can often be combined
into a single assignment.  If those assignments are to a struct field that
is narrower than int, results may be incorrect, especially if a
right-shift is involved.  

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.119, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 5.0.0B1 -
5.0.5, 5.1.0B1


Workaround: 
Do the operations in a local scalar variable instead of on the struct
fields.  Ie, instead of

  r.sb = r.sb ^ 0x8000u;
  r.sb = r.sb >> 1;
  r.sb = r.sb ^ 0x8000u;

do

  Uint16 x;
  x = r.sb;
  x = x ^ 0x8000u;
  x = x >> 1;
  x = x ^ 0x8000u;
  r.sb = x;

None.  The test case exceeds the limits of the optimiser.

------------------------------------------------------------------------------
FIXED  SDSCM00047463
------------------------------------------------------------------------------

Summary            : Instructions cbnz and cbz sometimes encoded incorrectly

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

Description: 
The assembler now emits an error when the cbnz or cbz instruction label
offset is not an even number.

Workaround: 
Ensure that the label is an even number. 

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

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

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

Description: 
The internal error was caused by attempting to place .cinit in a GROUP 
with .data in an ELF file.  This is not a recommended practice.  The
fix will allow .cinit and .data in a GROUP only if .data preceeds .cinit. 
In that case, compression of cinit records can not be performed.  If
.cnit is placed before .data in a GROUP, a user level error is reported.

Defect occurs in

TMS470 Compiler versions 4.9.0 - 4.9.8, 5.0.0B1 - 5.0.6, 5.1.0B1 -
5.1.1


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

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

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

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

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

Workaround: 
A workaround is to use --strict_ansi.


------------------------------------------------------------------------------
2. 4.9.8 Fixed Issues
------------------------------------------------------------------------------

------------------------------------------------------------------------------
FIXED  SDSCM00021302
------------------------------------------------------------------------------

Summary            : Format of constants in disassembly not consistent between
		     16 and 32 bit instructions for Thumb2

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

Description: 
The disassembler now displays all operand constants in hex or all
operand constants in decimal format.

Workaround: 
Use -e to view constants in hex format. 

------------------------------------------------------------------------------
FIXED  SDSCM00032000
------------------------------------------------------------------------------

Summary            : linker should not allows type flags on GROUP/UNION

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

Description: 
Update linker command file parser to disallow the type keyword if applied to a GROUP or UNION.

Workaround: 
None

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

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

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

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

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.118, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3


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

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

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

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

Description: 
The expression ...

  var_int16 = 4 * 256;

contains no implicit conversions.  However, MISRA rule 10.1 about no
implicit conversions is still emitted for that expression.

Workaround: 
None.

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

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

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

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

Defect occurs in

TMS470 Compiler versions 4.4.0 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 -
4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1,
4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.2


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

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

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

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

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

typedef unsigned int uint16_t;

uint16_t Func(void);

typedef enum Error
{
    OK,
    NO_DATA,
    BUFFER_FULL
} Error_t;

const Error_t errors[2] = {OK, OK};

uint16_t Func(void)
{
    uint16_t myError;

    myError = OK;    /* correctly flags as error (MISRA 10.1) */

    myError = errors[0];       /* does not find error */

    return myError;
}


Workaround: 
None.

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

Summary            : Instruction reordering alters logic

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

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

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


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

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

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

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

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

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

Summary            : Compiler generates Internal error Constant table error

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

Description: 
Compiler generates Internal error Constant table error

Workaround: 
There is an issue with the compiler pass that embeds constant
definitions so that the references to these constants efficiently reach
the definitions.  The issue manifests when encountering large string
constants that are placed close together in straight line code.  

A possible workaround is to try assigning pointers to the large string
constants and use the pointers.  For example

Instead of func(parm1,parm2, "A very long string constant ....") try

const char *sptr = "A very long string constant ...";

func(parm1,parm2,sptr);


------------------------------------------------------------------------------
FIXED  SDSCM00045036
------------------------------------------------------------------------------

Summary            : Internal error when no suitable delete operator is present
		     in destructor

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

Description: 
There are 3 delete operators as defined by the standard (6 if you count
array deletes)

void operator delete (void* ptr) throw ();

void operator delete (void* ptr, const stdnothrow_t& nothrow_constant)
throw(); 

void operator delete (void* ptr, void* voidptr2) throw();

The default operator delete is the first one there, and is required to
be visible to virtual destructor definitions. The one provided by the
code is the non-default third overloaded version of operator delete.
Another rule regards member functions, and states that if a member
function shadows a function declared in another scope, and the function
declared in another scope is overloaded, those overloaded functions are
invisible to the class.

With both of these code-related issues together, the compiler enters
into an erroneous state. The member function operator delete causes the
default operator delete to become invisible to the class' scope.
Finally, while defining the virtual destructor, a default delete
function cannot be found (which must be called according to the IA64
rules for virtual constructors), resulting in a segfault.

Workaround: 
The best workaround here is for the user to provide an appropriate
operator delete in the class.

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

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

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

Description: 
The C++ standard requires two distinct prototypes for qsort, one for 
comparison functions with C linkage, and one for comparison functions 
with C++ linkage.  The C++ linkage implementation was missing, which 
would lead to an incompatible parameter error when trying to use qsort
in C++ with a comparison function that has C++ linkage.

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.119, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 -
5.0.4, 5.1.0B1


Workaround: 
Declare the comparison function extern "C"

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

Summary            : Workaround for Stellaris ARM cache silicon errata

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

Description: 
Added a workaround for the silicon errata as described in the
document "Stellaris LM4FS1AH5BB Rev A1/A2". This workaround is enabled
through the --stellaris_cache_si_workaround compiler switch.

If a word-aligned value is loaded from an SRAM location into a core
register, then altered by storing a byte or halfword at an unaligned
offset, the altered word-aligned value is not correctly indicated when
loaded into a core register. The loaded value from the SRAM location
into a core register will reflect the original value, not the modified
value. The following assembly sequence causes the altered value loaded into a
core register to not load the correct value, even though the correct
value is visible in the SRAM memory location

  LDR  R0, [SP, #+0];
  STRB R0, [SP, #+1];  (STRH can cause silicon exception as well)
  LDR  R0, [SP, #+0];

This assembly sequence causes erroneous values only if these three
instructions are executed in this order. However, the three
instructions do not have to be consecutive, which means that other instructions can
be placed in between the first and the second instructions or the second
and the third instructions and the false value will still occur.

The solution  is to insert after the STR

  STR  V1, [SP, #-4];
  LDR  V1, [SP, #-4];

This forces the cached value to be reloaded from memory

The compiler switch will add the necessary extra STR, LDR instruction
to and from the stack. The --unaligned_access=on option cannot be used
with the --stellaris_cache_si_workaround switch.  If a user tries to do
so, a warning will be emitted and unaligned accesses will be disabled.


Workaround: 


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

Summary            : Linker generates unhandled exception when generating
		     dynamic library

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

Description: 
Linker sometimes generates unhandled exception when generating dynamic
library

The ELF executable was statically linked because it could not be
dynamically linked.  The executable should not have been statically
linked.  The linker now emits an error when an executable cannot be
statically or dynamically linked. 

Workaround: 


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

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

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

Description: 
If all of --exceptions, --unused_section_elimination=off, and 
--retain=.ARM.EXIDX are used, and the compiler turns a C++ function
into 
an alias (this is a TI-specific optimization), it is possible for the 
linker to retain the EXIDX section for the alias function but not the 
alias function itself, which leads to an internal error.

Defect occurs in

TMS470 Compiler versions 4.9.0B1 - 4.9.7, 5.0.0B1 - 5.0.4, 5.1.0B1


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

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

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

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

Description: 
The two statements

  a = x[0];
  memcpy(&x[0], &x[1], K);

may not occur in the correct order under certain conditions at -o2 and 
above.	The memcpy() may overwrite the first element before it is saved
in the variable.  The problem is specific to memcpy().

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3


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

the head be x[head] and implement the pop as head=(head+1)%arraysize.

Or use -o1 or -o0.

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

Summary            : Truncated pointer created by cast from integer constant

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

Description: 
For an expression of the form ((t *)c1+c2), where t is an arbitrary
type and c1 and c2 are integer constants small enough to fit in a type
smaller than int, the optimizer could mistakenly truncate the sum of
c1 and c2 to the smaller type.	It is possible for other optimizations
to create this expression through simplification of other expressions.

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3


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

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

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

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

Description: 
When multiplying a variable of a type the same size as int, or smaller,
by a constant power of two with a type wider than int, the compiler may
convert the multiply into a shift-left, and use the wrong type, thus 
computing the wrong answer.

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.2


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

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

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

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

Description: 
In some cases, the same code compiled with the same version of the 
compiler may produce different asm on Windows than on Linux.  The
reason is some unstable sorting of equivalent internal rules and inlineable
call sites.	The two systems will sort differently in these cases and the 
resulting asm will vary;  in some cases, performance will also be 
different.

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.2


Workaround: 
None.

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

Summary            : CCS disassembles FMRX and FMXR instructions incorrectly on
		     CortexR4

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

Description: 
CCS disassembles FMRX instruction as FMXR and FMXR instruction as FMRX
on CortexR4

The assembled FMRX instruction is incorrectly disassembled as a VMSR
instead of a VMRS instruction due to a decoding error.	The assembled
FMXR instruction is also incorrectly disassembled as a VMRS instead of
a VMSR instruction.

Workaround: 
No workaround 

------------------------------------------------------------------------------
FIXED  SDSCM00045894
------------------------------------------------------------------------------

Summary            : Use of option -pdse195 causes an incorrect error to be
		     generated

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

Description: 
An issue where diagnostics resulting from the evaluation of unused 
preprocessor tokens has been fixed. This issue only arose when error
#195 was escalated to warning or error. For example

When compiling the following code with the option -pdse195

   #define MY_CONCAT_DEFINE 1

   #define MY_CONCAT_MACRO(a, b) a##b

   #if (MY_CONCAT_MACRO(MY_,CONCAT_DEFINE) == 0)
     #error ("Define is zero")
   #endif

   int x;

The compiler generates the following incorrect error message

"test.c", line 5 error zero used for undefined preprocessing identifier
  #if (MY_CONCAT_MACRO(MY_,CONCAT_DEFINE) == 0)
       ^

"test.c", line 5 error zero used for undefined preprocessing identifier
  #if (MY_CONCAT_MACRO(MY_,CONCAT_DEFINE) == 0)
       ^

2 errors detected in the compilation of "test.c".

>> Compilation failure

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.117
- 4.4.10.118, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3

Workaround: 
Compiling without -pdse195 will remove the errors caused by this issue.
Alternatively, consider -pdsw195 if the diagnostic should be seen but
not bar the program from compiling.

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

Summary            : Recurrence with unsigned subscript can lead to wrong answer

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

Description: 
A loop with a recurrence like "x[i] =  ... x[i-1] ..." or "x[i+1] = ...

x[i] ..." may produce the wrong answers when i (or any other part of a 
complex subscript) is of an unsigned type.

Defect occurs in

TMS470 Compiler versions 4.8.0B1, 4.9.0B1 - 4.9.7, 5.0.0B1 - 5.0.3


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

------------------------------------------------------------------------------
FIXED  SDSCM00046175
------------------------------------------------------------------------------

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

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

Description: 
This bug could only happen in C++ code with exception turned ON.
Another added condition is that in this C++ code, there are excpetions thrown 
either in destructor or throw expression. When this bug happens, you
will see an error emitted from the compiler.

Defect occurs in

TMS470 Compiler versions 4.9.0B1 - 4.9.7, 5.1.0B1


Workaround: 
There is no work around for this bug.

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

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

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

Description: 
The compiler may mishandle C code with variables whose names resemble
C++ mangled names.	The one known instances is variables with a sequence of
four or more consecutive underscores (eg, "x_____y").  In this case,
one pass in the compiler dropped enough of the names to mistakenly think
two distinct variables were only one, leading to incorrect results.

Defect occurs in

TMS470 Compiler versions 4.9.0B1 - 4.9.7, 5.0.0B1 - 5.0.3


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

------------------------------------------------------------------------------
FIXED  SDSCM00046346
------------------------------------------------------------------------------

Summary            : Linker takes too long to link 

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

Description: 
Long link times can be caused by the linker's type merging pass to
reduce the debug section size. This problem is usually noticed in large
projects that contain several hundred files or more. This problem has been
addressed by an improved type merging algorithm that should reduce link times.

Defect occurs in

TMS470 Compiler versions 4.9.0B1 - 4.9.7, 5.1.0B1


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

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

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

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

Description: 
A bit-field may be assigned to with an op-assign (e.g. +=) operator.
If the left hand side of the operator is a bit-field and right hand
side is an expression with floating-point type, the compiler will in
some cases write a corrupted value to the bit-field.

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.118, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3


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

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

Summary            : Excessive compile time - Optimizer hangs

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

Description: 
A program containing large structs containing many fields, especially
if those fields are of type char, may require excessive time to compile.
The compiler must check all those fields for potential aliases, and
does so inefficiently.

Defect occurs in

TMS470 Compiler versions 2.209e, 2.40.beta - 2.71, 4.1.0B1 - 4.1.7,
2.54.02 - 2.54.209, 2.54.03 - 2.54.129, 2.202.03e - 2.202.15e, 4.4.0B1
- 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.119, 4.6.0B1 - 4.6.6,
4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7,
4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.4, 5.1.0B1


Workaround: 
None known.

------------------------------------------------------------------------------
FIXED  SDSCM00046847
------------------------------------------------------------------------------

Summary            : WEOF macro should be usable when included from cwctype
		     without a using declaration

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

Description: 
WEOF is a C99 macro with a value of type wint_t.  As a macro, the
namespace is not specified as you would for a type or variable
(stdwint_t).  When cwctype is included, the macro WEOF is defined
and should be usable without a using delcaration putting stdwint_t
in the global namespace.


Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.119, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 -
5.0.4, 5.1.0B1


Workaround: 
Add the declaration usingwint_t;

------------------------------------------------------------------------------
FIXED  SDSCM00046850
------------------------------------------------------------------------------

Summary            : Macro offsetof needs to be usable without using namespace
		     std for size_t

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

Description: 
offsetof is a macro involving the type size_t. As a macro, the
namespace is not specified as you would for a type or variable
(stdsize_t).  When cstddef is included, the macro offsetof is
defined and should be usable without a using delcaration putting
stdsize_t in the global namespace.

Defect occurs in

TMS470 Compiler versions 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100
- 4.4.10.119, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 -
4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 -
5.0.4, 5.1.0B2 - 5.1.0B1


Workaround: 
Add the declaration usingsize_t;


------------------------------------------------------------------------------
3. 4.9.7 Fixed Issues
------------------------------------------------------------------------------

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

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

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

Description: 
Linker now honors section placement specification.

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

Summary            : Enabling vectorization produces incorrect code

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

Description: 
In certain cases, enabling vectorization could result in incorrect code
being generated.

------------------------------------------------------------------------------
FIXED  SDSCM00044222
------------------------------------------------------------------------------

Summary            : Arm _set_interrupt_priority intrinsic and C6x __mfence()
		     intrinsic should be treated as a barrier in the compiler.

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

Description: 
There are 2 intrinsics that should be treated as a barrier in the
compiler but are not. They are

1. C6x _mfence intrinsic
2. ARM _set_interrupt_priority intrinsic

This means that loads and stores (memory operations) above and below
the intrinsics should not move across the intrinsic. It is possible
that such an instruction could be scheduled before or after the
intrinsic. 

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

Summary            : FPEXC register not properly restored before existing
		     assembly function

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

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

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

Summary            : scanf %[^ mistakenly writes EOF to output

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

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

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

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

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

Description: 
LDM instruction "LDM sp!, {lr}" generates internal error unexpected
operand in LDM/STM conversion

The compiler now accepts LDM instructions with only one register in the
register list operand.

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

Summary            : Parser allows virtual base classes that are too large

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

Description: 
In EABI, due to the RTTI implementation, the compiler can only handle 
virtual base classes of a certain size.  The parser incorrectly
computed this size and did not emit a warning for very large virtual base
classes that were too large. This would lead to data corruption.

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

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

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

Description: 
The fix to CQ44227 creates an object code incompatibility with object
code from previous toolsets, which can cause a C++ program consisting
of code from both to fail to link.

CQ44227 was an issue with static data members of template classes and
functions, which require an initialization guard variable to insure
one-time initialization. The guard variable was introduced into the
same COMDAT section as the static data member.

The issue is that if code from an older toolset (which does not contain
the guard) is linked with code from a newer toolset (which does), the
linker may choose the COMDAT group without the guard, thus leaving no
definition for the guard. This can trigger an undefined symbol error,
or, if the object code is in a library, cause the linker to hang. 

This problem occurs only under the following conditions
- a static variable in a template function or static data member
requires initialization by constructor (as described in CQ44227)
- For C6x, the program includes object code compiled by version 7.3.6
of the C6x compiler, as well as object code compiled by an eariler
version.
- For ARM, the program includes object code compiled by version 4.9.6
or 5.0.0, as well as object code compiled by an earlier version. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Description: 
If a struct contains another struct, and the inner struct has no
fields, and the parent struct is copied whole through an assignment of 
struct-type variables, the optimiser may abort.

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

Summary            : Incorrect linker symbol value after multiple partial links
Fixed in           : 4.9.7
Severity           : S2 - Major
Affected Component : ELF Linker

Description:
Linker symbols whose values depend on section placement were getting assigned 
absolute values instead of section relative values in partial links.  These are 
symbols that are defined using the '.' operator, and/or those defined using the 
linker command file keywords such as START, END, LOAD_START etc.

As a result, the final link would assign incorrect values to these symbols.  


------------------------------------------------------------------------------
4. 4.9.6 Fixed Issues
------------------------------------------------------------------------------

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

Summary            : Compiler optimizes away certain calls to assert()

Fixed in           : 4.9.6
Severity           : S3 - Minor
Affected Component : Absolute Lister

Description: 
Certain assert() statements, most notably "assert(x&1)" and the 
equivalent "assert(x%2==0)", may be removed by the compiler and thus
will not do the run-time condition check that is desired.

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

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

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

Description: 
In the attached file, the class member Aoperation uses string literals.
Instead of creating the string literals the parser is generating static
char array member and initializes it to the string chars.

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

Summary            : Linker fails with internal error

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

Description: 
Linker sometimes fails with internal error lnk470.exe experienced an
unhandled exception

The linker no longer makes the assumption that the decompression
routine's section can be automatically removed when the linker
determines the decompression routine is not needed.

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

Summary            : IF predicate with negative integer factor simplifies
		     incorrectly

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

Description: 
An IF predicate with a negative integer factor -- eg, "if (x*(-3) ==
-9)" -- may be simplified incorrectly, for instance to "if (x == -3)"
instead of the correct "if (x == 3)".

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

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

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

Description: 
If two three-operand expressions using the same associative operator
and two of the same operands occur in the same function -- for example,
x*x*x and 30*x*x -- the second expression may miscompile and be treated as 
identical to the first.

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

Summary            : opt470 experienced a segmentation fault

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

Description: 
Corrected false assumption made while performing an optimization.

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

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

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

Description: 
In EABI mode, static variables in template functions and static data
members of template classes may not be properly allocated and/or
initialized.  Templates are typically defined in header files,
resulting in separate instances in each translation unit (source file).
The tools must merge these multiple instances into unique instances,
and ensure that static objects are allocated and initialized only once.
There are three specific cases in which these mechanisms may fail,
resulting in incorrect behavior of the program. They are

1. A static variable in a template function, or a static variable in a
member function of a template class, may not be allocated as a single
unique object.	This error occurs only when all of the following
conditions occur
   - the function is not declared inline, AND
   - the function is not implicity inline by virtue of having its body
defined within the template class, AND
   - the function body is compiled in multiple translation units (i.e.
the definition is in a header file).  

For example

   template <class T>
   void f()
   { 
      static int var; 
      // ...
   }

If this function definition is compiled into multiple translation
units, the compiler may incorrectly create multiple instances of 'var'.

Additionally, the compiler may incorrectly allocate 'var' into a
section with other variables. This may cause unexpected behavior during
linking, such as incorporating of unreferenced sections into the link,
or changing the contents of the data section from link to link
(depending on which copy of 'f()' arbitrarily gets linked in).

A workaround for this defect is to declare the function f() as inline.

2. Under the same conditions described in case 1, if the static
variable is initialized with a constructor, the constructor may
incorrectly be called multiple times.

For example 

   template <class T> 
   void f() 
   {
      static T var;
      // ...
   }

The constructor TT() may be called multiple times to initialize 'var'. 
Declaring f() as inline also works around this problem. 

3. Similarly, if a static data member of a template class is
initialized with a constructor, the constructor may incorrectly be
called multiple times.	This occurs only when all of the following
conditions occur
   - the definition (not the declaration) of the data member appears in
multiple translation units, AND
   - the member is referenced in multiple translation units in which
the definition occurs.

For example

   template <class T>
   class MyClass
   {
      static T var;	// declaration
   };

   // definition
   template <class T> 
   T MyClass<T>var;   // may call TT() multiple times

A workaround for case 3 is to move the definition from a header file to
a .cpp file, so that it only occurs once.


------------------------------------------------------------------------------
5. 4.9.5 Fixed Issues
------------------------------------------------------------------------------

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

Summary            : Partial link drops weak function symbol

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

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

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

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

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

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

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

Fixed in           : 4.9.5
Severity           : S2 - Major
Affected Component : C/C++ Compiler

Description: Please reference the Gladiator errata SPNZ181, Cortex-R4#57
http://www.ti.com/lit/er/spnz181a/spnz181a.pdf 

The --arm_vmrs_si_workaround=on|off option was added to prevent a conditional 
VMRS instruction from being generated by the compiler.  By default, the option is 
enabled (on).  A warning will be emitted if a developer attempts to add a 
conditional VMRS instruction to the assembly file when the option is enabled.  
The developer can turn the option off using --arm_vmrs_si_workaround=off.

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

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

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

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

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

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

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

Description: 
Given an IF with a predicate like "(x >> k1) < k2", the compiler will 
attempt to convert it to "x < (k2<<k1)".  If k2 is a literal or const 
variable whose type is too small to hold k2<<k1, the result will be 
incorrect.  The compiler should use a wider type, the promoted type of 
x;  the workaround is to do the same thing in the source.

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

Summary            : Linker cannot find include file specified with relative
		     path

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

Description: 


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

#define SPACE
#include "../first.cmd"
SPACE
#include "../second.cmd"


------------------------------------------------------------------------------
6. 4.9.4 Fixed Issues
------------------------------------------------------------------------------

------------------------------------------------------------------------------
FIXED  SDSCM00042570
------------------------------------------------------------------------------

Summary            : Missing MISRA 19.15

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

Description: 
MISRA 19.15 not selectable in CCS v5.1.

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

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

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

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

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

Summary            : Assembler generates segmentation fault

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

Description: 
Assembler generates segmentation fault with an asm statement 
that attempts to access a C function parameter.

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

Summary            : CDP instruction not accepted for v4 versions

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

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

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

Summary            : Compiler incorrectly rewrites expression as rotate
		     operation

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

Description: 
An expression such as

(ptr->obj->a << 16) | (ptr->obj->b >> 16) 

does not produce correct code, with the right shift and or not being 
included in the generated code.

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

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

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

Description: 
The optimiser may issue alias advice that refers to the optimiser's 
temporary symbols, whose declarations the user cannot control.	This 
advice does not affect the code's behavior, though it leaves some 
suggested improvements inaccessible.

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

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

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

Description: 
In a particular situation involving a struct containing an array of 
structs, the compiler may miss an alias between a read and write of a 
scalar field in the nested struct.

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

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

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

Description: 
The optimiser may crash when it encounters an extremely long type name
-- 
for example, a deep nested templated C++ class name -- while creating a
printed representation.  The crash is most likely, and perhaps only 
occurs, with -o2 or -o3.


------------------------------------------------------------------------------
7. 4.9.3 Fixed Issues
------------------------------------------------------------------------------

------------------------------------------------------------------------------
FIXED  SDSCM00037170
------------------------------------------------------------------------------

Summary            : Embed does not handle cross-filesystem rename correctly

Fixed in           : 4.9.3
Severity           : S2 - Major
Affected Component : Embed Utility

Description: 
The embed utility needs to copy the file across file systems before
renaming it.

------------------------------------------------------------------------------
FIXED  SDSCM00040101
------------------------------------------------------------------------------

Summary            : Compiler generates temporary files when compiling C++ files
		     with templates and -pm that are not automatically deleted

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

Description: 
When compiling C++ files which use templates with -pm option the
compiler generates temporary files that are not automatically deleted.

------------------------------------------------------------------------------
FIXED  SDSCM00042012
------------------------------------------------------------------------------

Summary            : The .TI.symbol.alias section has an invalid sh_type field
		     for ARM

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

Description: 
The section, .TI.symbol.alias, receives an invalid sh_type in ARM
object files. The type should be SHT_PROGBITS, but it is set to 0x70000006, 
which is reserved by the ARM EABI. This should not cause any issues
when linking with the TI tools, but it can cause other vendors to reject the
object files when linking. The other potential issue is if this flag is
interpreted differently in the future because ARM assigned some
property to the type number.

------------------------------------------------------------------------------
FIXED  SDSCM00042053
------------------------------------------------------------------------------

Summary            : Near a loop that comes from an include file, the .dwpsn 
                     directives have the wrong file name

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

Description: 
Fixed a bug where debug information near an inlined loop could contain 
the incorrect file name.

------------------------------------------------------------------------------
FIXED  SDSCM00042340
------------------------------------------------------------------------------

Summary            : Compiler mistakenly issues diagnostic about destructor for
		     base class is not virtual

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

Description: 
The no virtual base class destructor diagnostic will no longer be
emitted when the base class has a virtual destructor.  

------------------------------------------------------------------------------
FIXED  SDSCM00042368
------------------------------------------------------------------------------

Summary            : Parser generates segmentation fault

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

Description: 
Parser generates segmentation fault when compiling the following source
file

static const int a[1];

int main(void)
{
    (void)a[0];

    return 0;
}

static const int a[1] = { 0 };

------------------------------------------------------------------------------
FIXED  SDSCM00042506
------------------------------------------------------------------------------

Summary            : Quest/colon (?) expression on floats, cast to int, may
		     cause compiler hang

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

Description: 
The compiler may hang in the optimiser stage when given a quest/colon 
(?) expression of floating-point type which is cast to int, when 
compiling at -o2 or higher.  The problem is specific to ?, not to other
expressions, and requires the mixture of floating and integral types.

------------------------------------------------------------------------------
FIXED  SDSCM00042511
------------------------------------------------------------------------------

Summary            : Parser crash

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

Description: 
The seg fault occurred because a static const variable definition appeared
after the variable reference.  The parser made a false assumption that a definition
must appear before the reference. As a result, the parser
improperly removed the static const definition, causing a seg fault. 
This false assumption has been removed.

------------------------------------------------------------------------------
FIXED  SDSCM00042541
------------------------------------------------------------------------------

Summary            : C math library drags in feraiseexcept and malloc, which is
                     undesirable
Fixed in           : 4.9.3
Severity           : S3 - Minor
Affected Component : Runtime Support Libraries (RTS)

Description:
The raise() function has been changed to avoid calling fputs(). The default 
handling of signals has been changed to do nothing. This can be changed by using 
the signal() function to install custom handlers.

------------------------------------------------------------------------------
FIXED  SDSCM00042542
------------------------------------------------------------------------------

Summary            : Some math functions like ldexp() will cause fputs and its
                     required functions like malloc to be included
Fixed in           : 4.9.3
Severity           : S2 - Major
Affected Component : Runtime Support Libraries (RTS)

Description:
The floating point math functions contain calls to catch floating point 
exceptions. These calls eventually call the raise() function, which by default 
uses fputs() to relay the exception to the user. This is incorrect. The 
raise() function will be altered to do nothing by default.

------------------------------------------------------------------------------
FIXED  SDSCM00042563
------------------------------------------------------------------------------

Summary            : Optimiser crashes on certain loop cases

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

Description: 
Certain loop structures, which we are not able to describe concisely,
can cause the optimiser to crash when compiling at -o2 or higher.  The
one known example involves C++ code and a lot of inlining;  adjusting
the inlining avoids the problem.

------------------------------------------------------------------------------
FIXED  SDSCM00042604
------------------------------------------------------------------------------

Summary            : The ARM compiler does not correctly set the last bit for
		     thumb function symbol values.

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

Description: 
This bug will cause interlinking problems with other vendors linkers.
The GCC linker is known to rely on the last bit to determine if a BL needs
to be converted to a BLX instruction. This bug will cause applications
with object files produced by the TI compiler and consumed by the GCC linker
to fail if thumb instructions are used.

------------------------------------------------------------------------------
FIXED  SDSCM00042632
------------------------------------------------------------------------------

Summary            : Functions declared static get global visibility when
		     compiled with optimization in EABI mode

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

Description: 
Fixed a bug wherein two functions, one static and one global where one
function contains code and the other simply calls the first, were
aliased together, essentially removing the static state of one function
and causing it to be visible globally.

------------------------------------------------------------------------------
FIXED  SDSCM00042640
------------------------------------------------------------------------------

Summary            : Function-like macros in Compiler.h should not have space
		     between name and left paren

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

Description: 
The macros defined in Compiler.h that take arguments have a space
between the identifier and open parenthesis which causes the arguments to be
part of the macro expansion.

------------------------------------------------------------------------------
FIXED  SDSCM00042653
------------------------------------------------------------------------------

Summary            : When generating VFP code, the presence of an interrupt in a
		     file may cause other functions in that file to save the FPSCR

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

Description: 
This is a performance bug and should not cause incorrect code. The
issue is that sometimes the FPSCR and FPEXC registers will be saved to the
stack needlessly upon entry to a function.


------------------------------------------------------------------------------
8. 4.9.2 Fixed Issues
------------------------------------------------------------------------------

------------------------------------------------------------------------------
FIXED  SDSCM00040065
------------------------------------------------------------------------------

Summary            : dis470, ofd470 crash with IAR object code, ARM linker does
		     not handle R_ARM_THM_PC12 relocation
		     type correctly

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

Description: 
The linker will produce overflow warnings for relocations on ARM. The 
specific relocation that caused this to be noticed is the ARM_THM_PC8 
type. The ARM ELF manual states that only the R_ARM_ABS16, R_ARM_ABS8, 
and R_ARM_PREL31 types should have overflow checking done. The rest of 
the relocation types should have their results masked off before being 
written. The resulting output file should be correct if these warnings 
are generated, but the file should inspected to ensure the correct
value was generated for each relocation warning

------------------------------------------------------------------------------
FIXED  SDSCM00040151
------------------------------------------------------------------------------

Summary            : Getting compile time generated symbol re-definition error
		     during linking C674x ELF target

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

Description: 
The linker may generate "duplicate symbol" errors for symbols named
like _TI_DW_.debug_info.<checksum> when linking object files.  Using ofd, it
can be seen that these symbols are signatures for COMDAT groups.  This
is an error in COMDAT generation in the assembler and linker.

------------------------------------------------------------------------------
FIXED  SDSCM00040650
------------------------------------------------------------------------------

Summary            : Error when specifying 400 or more to precision of output
		     format specifier

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

Description: 
The minimum max conversion (precision) printf size to be C89 compliant
is 509.   The conversion size is now C89 compliant.

------------------------------------------------------------------------------
FIXED  SDSCM00040698
------------------------------------------------------------------------------

Summary            : Optimiser may crash if given loop nest in which innermost
		     loop unconditionally returns

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

Description: 
A loop nest with an inner loop that returns unconditionally may cause
the optimiser to crash.

------------------------------------------------------------------------------
FIXED  SDSCM00041565
------------------------------------------------------------------------------

Summary            : Optimizer error, 2-dimensional array, 2 multiplications

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

Description: 
The optimiser may abort if it encounters a sum of a pair of multiplies 
which can be represented as a _dotp2 call, if the operands are adjacent
array references.  Multiplies of scalar variables are not affected, and
_dotp2 possibilities that require unrolling a loop are not affected.

------------------------------------------------------------------------------
FIXED  SDSCM00041569
------------------------------------------------------------------------------

Summary            : Optimizer removes weak object pointer check

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

Description: 
The optimiser believed that UAND-of-NAME was always non-NULL.  That's
not true for weak symbols.

------------------------------------------------------------------------------
FIXED  SDSCM00041776
------------------------------------------------------------------------------

Summary            : Optimizer substitutes packed bitfield reference without
		     masking value at -o1

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

Description: 
Under certain specific circumstances, the compiler may replace an
assignment to a bitfield with a temporary variable whose value has not
been properly truncated as the original assignment did.  To cause the
bug, several passes that do the right thing must be inhibited;	one
known way is to use -o1 and a packed struct.

------------------------------------------------------------------------------
FIXED  SDSCM00041786
------------------------------------------------------------------------------

Summary            : Certain oversized vectorisation cases cause optimiser crash

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

Description: 
Certain very wide vectorisation cases may cause an 
optimiser crash.  Loops involving operations with one short operand and
one int operand may trigger the crash.	Loops doing a saturated 
subtraction of shorts and saving the result in a short may trigger the 
crash.	In both cases, an UNROLL pragma will work around the problem;  
see Workarounds.

------------------------------------------------------------------------------
FIXED  SDSCM00041828
------------------------------------------------------------------------------

Summary            : Internal error when compiling c++ code

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

Description: 
Use of an anonymous namespace in eabi mode causes a parser crash

namespace {
   class X  public Y {
      public
	 X ()  Y("Test") { }
   };
}

cl470.exe -mv7M3 -g -me --abi=eabi t.cpp

INTERNAL ERROR acpia470 experienced a segmentation fault while
		processing

------------------------------------------------------------------------------
FIXED  SDSCM00041888
------------------------------------------------------------------------------

Summary            : Compiler incorrectly exposes static function as global,
		     when building with optimization and EABI

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

Description: 
Fixed bug where a static function that only calls another function
would be considered a global symbol.

The .symalias assembly directive turns any symbol attached to it into a
global symbol. When compiling in EABI mode, if a static function is 
aliased with another function, it will be exposed incorrectly as a
global symbol.

------------------------------------------------------------------------------
FIXED  SDSCM00041925
------------------------------------------------------------------------------

Summary            : C++ name mangling for global string object causes linker
		     conflict if project contains files with same filename

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

Description: 
In a project where global stdstring objects are defined with different
names but in files in different directories but with the same filename,
the linker generates a multiply defined error message for the objects.

------------------------------------------------------------------------------
FIXED  SDSCM00042007
------------------------------------------------------------------------------

Summary            : The opcode generated by compiler for STREXH and STREX
		     instructions is incorrect

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

Description: 
The opcode generated by the compiler for STREXH and STREX instructions
is incorrect.

The STREXH instruction in assembly source is replaced with a STREXB
opcode.  The STREX R2, R0, [R1] instruction is disassembled as STREX PC, R0,
[R1, #8] 

------------------------------------------------------------------------------
FIXED  SDSCM00042061
------------------------------------------------------------------------------

Summary            : Library building fails when TEMP is moderately long (50+
		     characters)

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

Description: 
The ar470 command line is over 32k characters, which runs afoul of the
insurmountable upper limit of the Win32 API CreateProcess.  When this
happens, the user will see a mysterious error which looks something
like this

    process_begin
    CreateProcess(c\progra~1\texasi~1\tms470~2.1\bin\ar470.exe,
    c/progra~1/texasi~1/tms470~2.1/bin/ar470 -qa
    c/docume~1/user.name/locals~1/temp/ti5b2e~1/rtsv7a8_a_le_eabi.lib
    c/docume~1/user.name/locals~1/temp/ti5b2e~1/obj/decode.obj
    <over 500 object files listed here were deleted for clarity>
    c/docume~1/user.name/locals~1/temp/ti5b2e~1/obj/xatexit.obj, ...) 
    failed.
    make (e=87) The parameter is incorrect.

------------------------------------------------------------------------------
FIXED  SDSCM00042103
------------------------------------------------------------------------------

Summary            : Dynamic linking options should be hidden for non-C6000
		     targets

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

Description: 
Dynamic linking is not supported for any target but C6000, but the
dynamic linking options were exposed in the shell and linker option
help summary output.  Ignore them.

------------------------------------------------------------------------------
FIXED  SDSCM00042132
------------------------------------------------------------------------------

Summary            : Code moved before NULL pointer check in 'if' statement

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

Description: 
Given a sequence like

  pqd = ((pq)->dynamic);
  if ( (((pqd)==0) ? pq->queue[0]  pq->queue[pqd->head]) == qent )

the compiler may arrange to dereference pqd->head before it has tested 
that pqd is non-NULL, causing incorrect behavior if the processor traps
on the bad access.

------------------------------------------------------------------------------
FIXED  SDSCM00042140
------------------------------------------------------------------------------

Summary            : Assembler incorrectly encodes PKHTB instruction if no shift
		     argument is given

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

Description: 
The PKHTB <Rd>, <Rm>, <Rn> instruction is a pseudo-instruction of PKHBT
<Rd>, <Rn>, <Rm>. The assembler incorrectly assembles this instruction
as PKHTB <Rd>, <Rm>, <Rn>, ASR #32. 

------------------------------------------------------------------------------
FIXED  SDSCM00042146
------------------------------------------------------------------------------

Summary            : Quotes in PATH, TEMP, etc on Windows breaks mklib

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

Description: 
If the PATH environment variable has quotes in it, mklib will crash
with a mysterious error like "CreateProcess(NULL, cl470 atexit.c ...) 
failed.  The system cannot find the file specified."  It is not legal
to have literal quotes in PATH, but as an enhancement, mklib will
attempt to remove quotes from PATH and try again.

------------------------------------------------------------------------------
FIXED  SDSCM00042149
------------------------------------------------------------------------------

Summary            : Signed bitfield in union with unsigned integer treated as
		     unsigned

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

Description: 
Given a union containing a scalar integer field and a struct field 
consisting entirely of bitfields, such that the integer and the
bitfield struct have the same number of bits, a signed bitfield may be treated 
(incorrectly) as unsigned if the scalar integer is unsigned.


------------------------------------------------------------------------------
9. 4.9.1 Fixed Issues
------------------------------------------------------------------------------

------------------------------------------------------------------------------
FIXED  SDSCM00031246
------------------------------------------------------------------------------

Summary            : Zero length Section allocation problem

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

Description: 
A zero length output section in a linker command file that contains the
dot expression . += 0x0 will cause a linker error

   .trace fill = 0x0 {
	   _SYS_PUTCBEG = .;
	   . += 0x0;
	   _SYS_PUTCEND = . - 1;
	} > L1SARAM PAGE 1


   placement fails for object ".trace", size 0x0 (page 1).  Available
ranges
   L1SARAM	size 0x1000	  unused 0x22e	      max hole 0x22c   
 
   error errors encountered during linking;

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

Summary            : Linker generates relocation errors for symbols already in
		     bss

Fixed in           : 4.9.1
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 llinked 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 support by the current
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  SDSCM00039539
------------------------------------------------------------------------------

Summary            : Problem with register save/restore for function

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

Description: 
In certain cases, register save and restore in a function appears to be
incorrect.  In the case reported, a returned value is overwritten.

The store of the function return value to the return register memory
location on the stack must happen immediately before the return
register is popped off the stack. 

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

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

Fixed in           : 4.9.1
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  SDSCM00039655
------------------------------------------------------------------------------

Summary            : ARM linker fails when generating BE-8 code from a partially
		     linked object file

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

Description: 
This bug has the following requirements

1. The link must be generating BE-8 code
2. The object file format must be ELF.
3. A relocatable input file must have a code section that starts at a
non-zero address.

The only way to generate an ELF relocatable file with a section with a 
non-zero address is through partial linking. 

------------------------------------------------------------------------------
FIXED  SDSCM00039690
------------------------------------------------------------------------------

Summary            : Compiling with VFPv3D16 causes internal error

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

Description: 
This bug can occur when returning a structure from a function where the
structure is returned in VFP registers. This can occur if the structure
is either all float or all double and has no more than 4 fields.

------------------------------------------------------------------------------
FIXED  SDSCM00040062
------------------------------------------------------------------------------

Summary            : ARM compiler does not support the ARM_THM_PC8 relocation
		     type

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

Description: 
This relocation type is not generated by the TI toolchain. It is 
generated by the IAR compiler for loading data from literal pools.

------------------------------------------------------------------------------
FIXED  SDSCM00040264
------------------------------------------------------------------------------

Summary            : optimizer reduces WRITE to volatile in a loop to a single
		     WRITE to volatile after the loop

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

Description: 
A volatile access may not be properly handled if the volatile qualifier
is only present on the field in the definition of a struct, as opposed
to the struct type as a whole or the variable itself.

------------------------------------------------------------------------------
FIXED  SDSCM00040365
------------------------------------------------------------------------------

Summary            : Mixing direct and indirect accesses to same variable may
		     give wrong answer

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

Description: 
Referring to the same variable both directly and indirectly -- eg,
given p[0]=&a, using both *p[0] and a in the same function -- may produce the
wrong answer when the alias between the two references is missed.

------------------------------------------------------------------------------
FIXED  SDSCM00040369
------------------------------------------------------------------------------

Summary            : Assignment to local struct variable with recurrence may
		     assign some fields incorrectly

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

Description: 
Given a struct type that contains a pointer to the same type, as in

  struct st {
      struct st *next;
      int    val;
  }

and a local variable X of that type, and an assignment to that variable
like

  X = *(X.next);

some fields of X may not be written correctly.	(Because X.next is
written before the read of *(X.next) has completed.)

------------------------------------------------------------------------------
FIXED  SDSCM00040372
------------------------------------------------------------------------------

Summary            : Variable with volatile inside loop resulted in codegen
		     INTERNAL ERROR.

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

------------------------------------------------------------------------------
FIXED  SDSCM00040377
------------------------------------------------------------------------------

Summary            : Error with va_end() as left operand of void expression

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

Description: 
The macro va_end should be legal in a void expression context such as
the left hand operand of the comma operator.  This means the macro needs to
expand to a void expression rather than be an empty macro.

------------------------------------------------------------------------------
FIXED  SDSCM00040400
------------------------------------------------------------------------------

Summary            : Bitfield alias may be missed when struct is smaller than
		     field type

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

Description: 
An alias may be missed, and incorrect answers result, when a struct 
contains a bitfield and the struct's total size is smaller than the
size of the bitfield's type.  Eg, a field like "int x6" -- the bitfield is 6
bits but int is 16 or 32.  Making both direct and indirect accesses to 
the same field may be an additional requirement to exhibit this
problem.

------------------------------------------------------------------------------
FIXED  SDSCM00040459
------------------------------------------------------------------------------

Summary            : Division or modulo by most-negative-value of type may
		     produce incorrect answer

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

Description: 
Division or modulo when the divisor is the most-negative-value of a 
signed type (eg, -128 for signed-char for C6x) may produce the wrong 
answer. 

------------------------------------------------------------------------------
FIXED  SDSCM00040487
------------------------------------------------------------------------------

Summary            : packed attribute given before the member list of a CSU may
		     produce bad code

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

Description: 
A class/union/struct type declared with the packed attribute preceding 
its member list can result in the generation of incorrect code.

------------------------------------------------------------------------------
FIXED  SDSCM00040497
------------------------------------------------------------------------------

Summary            : DSECT failure

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

Description: 
In some cases, code allocated to a DSECT type output section may be 
included in the output file.  This is known to occur if the code in the
DSECT references a function that is not allocated to a DSECT.

------------------------------------------------------------------------------
FIXED  SDSCM00040552
------------------------------------------------------------------------------

Summary            : The math.h header file violates EABI by exposing internal
		     functions suchas _Sin

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

Description: 
This problem should only affect users trying to interlink with other 
vendors, specifically using TI produced object files with another
vendor's linker. The user will most likely experience an unresolved
symbol error. Affected functions include cos, cosh, log, log10, sin,
sinh, and log2 (including single and long double variants).

------------------------------------------------------------------------------
FIXED  SDSCM00040610
------------------------------------------------------------------------------

Summary            : The ARM compiler does not save the FPEXC register upon
		     entry to an interrupt function.

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

Description: 
The FPEXC register is now saved upon entry to an interrupt function.

------------------------------------------------------------------------------
FIXED  SDSCM00040622
------------------------------------------------------------------------------

Summary            : Compiler may miss alias of struct returned from call if
		     contains bitfield and fits in int

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

Description: 
The compiler may convert local struct variables of struct type into
simple ints, if the struct is small enough and all fields are bitfields.  If 
such a converted struct is also returned from a function call, the 
compiler may miss an alias between the returned-value struct and the 
local struct.

------------------------------------------------------------------------------
FIXED  SDSCM00040623
------------------------------------------------------------------------------

Summary            : Mixing direct and indirect accesses to same variable may
		     give wrong answer

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

Description: 
Referring to the same variable both directly and indirectly -- eg,
given p=&a, using both *p and a in the same function -- may produce the wrong
answer when the alias between the two references is missed.

------------------------------------------------------------------------------
FIXED  SDSCM00040651
------------------------------------------------------------------------------

Summary            : Return statement with embedded assignment from a
		     post-increment or -decrement may return wrong value

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

Description: 
A statement like "return j = i++" may return the value of i after it
has been incremented, when it should return the value before the increment.
 
It's possible that other cases exist, but all will involve an
assignment of a post-increment or post-decrement embedded in another statement.

------------------------------------------------------------------------------
FIXED  SDSCM00040658
------------------------------------------------------------------------------

Summary            : Taking the address of a static local variable may lead to a
		     missed alias

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

Description: 
Accessing a static local variable both directly and indirectly, by
taking its address, may miss an alias and produce incorrect behavior.

------------------------------------------------------------------------------
FIXED  SDSCM00040659
------------------------------------------------------------------------------

Summary            : Mixing direct and indirect accesses to same variable may
		     give wrong answer

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

Description: 
Referring to the same variable both directly and indirectly -- eg,
given p=&a, using both *p and a in the same function -- may produce the wrong
answer when the alias between the two references is missed.

------------------------------------------------------------------------------
FIXED  SDSCM00040665
------------------------------------------------------------------------------

Summary            : Anonymous function call that can resolve to direct pure
		     call may cause compiler crash

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

Description: 
If an anonymous function call -- a call using a pointer-to-function 
variable rather than a direct function name -- can be resolved to a 
direct call to a known function with no side effects, in some cases the
compiler may crash.

------------------------------------------------------------------------------
FIXED  SDSCM00040698
------------------------------------------------------------------------------

Summary            : Optimiser may crash if given loop nest in which innermost
		     loop unconditionally returns

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

Description: 
A loop nest with an inner loop that returns unconditionally may cause
the optimiser to crash.

------------------------------------------------------------------------------
FIXED  SDSCM00040793
------------------------------------------------------------------------------

Summary            : Accessing the same variable both directly and via
		     pointer-to-void may miss the alias

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

Description: 
If the same variable is referred to both directly and via a 
pointer-to-void parameter, the compiler may not detect that both
accesses are to the same variable.

------------------------------------------------------------------------------
FIXED  SDSCM00040908
------------------------------------------------------------------------------

Summary            : Hex converter crashes with segmentation fault

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

Description: 
Hex converter crashes with segmentation fault if more than 15 --exclude
options are used.

------------------------------------------------------------------------------
FIXED  SDSCM00041342
------------------------------------------------------------------------------

Summary            : The ARM compiler does not generate correct code for
		     interrupts in Thumb-2 mode

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

------------------------------------------------------------------------------
FIXED  SDSCM00041349
------------------------------------------------------------------------------

Summary            : Packed struct containing struct may cause optimiser abort

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

Description: 
Given a struct with attribute "packed," which contains as a field
another struct, with a total size no more than 64 bits, and a struct assignment
whose right-hand side is const (declaring a struct with an 
auto-initialisation will make such an assignment), the optimiser may
abort.

------------------------------------------------------------------------------
FIXED  SDSCM00041391
------------------------------------------------------------------------------

Summary            : The _sxth, _sxtb, _uxtb, and _uxth intrinsics should be
		     supported for Cortex-M3

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

Description: 
The compiler supports intrinsics for SXTB, SXTH, UXTB, and UXTH 
instructions. These are supported for Cortex-M3, but were not accepted
as intrinsics for that target.

------------------------------------------------------------------------------
FIXED  SDSCM00041395
------------------------------------------------------------------------------

Summary            : scanf %1f should stop after one character

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

Description: 
The scanf format %1f should stop after one character of input, but it 
ignores the field width and keeps parsing as long as the input looks
like a floating-point number.

------------------------------------------------------------------------------
FIXED  SDSCM00041396
------------------------------------------------------------------------------

Summary            : sscanf(" ", "%s", arg) should not modify arg

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

Description: 
When the scanf format %s is used, if there are no non-whitespace 
characters in the input, the conversion should fail and should not
modify the argument.

------------------------------------------------------------------------------
FIXED  SDSCM00041397
------------------------------------------------------------------------------

Summary            : scanf %4[..] consumes 5 characters

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

Description: 
With a format string containing a %[ conversion specifier with field
width, and input containing a sequence of characters that matches the
scanset and has more characters than the field width, a call to vfscanf
shall assign the number of characters equal to the field width to the
corresponding pointer to character array leaving characters after the
input item unread. 7.19.6.9;2a (161)	

The bug here is that, while _scanfi assigns the correct number of 
characters, it fails to unget the following character, which belongs to
the next conversion.

------------------------------------------------------------------------------
FIXED  SDSCM00041398
------------------------------------------------------------------------------

Summary            : scanf %[..] matching failure should return immediately

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

Description: 
When a conversion fails, scanf should return immediately.  In these
test cases, scanf erroneously keeps going.  scanf eventually reports a
return value that is too large.

------------------------------------------------------------------------------
FIXED  SDSCM00041442
------------------------------------------------------------------------------

Summary            : printf("%#.4o",345) adds too many zeros

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

Description: 
When using the # printf format flag, printf should only add an extra
"0" at the beginning of the number if it isn't already "0".

------------------------------------------------------------------------------
FIXED  SDSCM00041447
------------------------------------------------------------------------------

Summary            : printf("%#.0o",0) fails to write "0"

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

Description: 
For *printf functions, the C standard requires that if the value is 0,
the precision is 0, and the # flag is used, a single "0" will be
printed.

------------------------------------------------------------------------------
FIXED  SDSCM00041550
------------------------------------------------------------------------------

Summary            : sscanf %% failure not handled correctly

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

Description: 
scanf fails in these ways when the %% conversion specifier fails
When any sort of error occurs with %%, scanf immediately returns EOF. 
It should instead return EOF only if there were 0 previous successful
conversions and there was an input failure.  If the failure was either
a matching failure, or there were any previous successful conversions,
it should return the number of previous successful conversions.

When the failure is a matching failure, scanf should unget the
character that didn't match.  It fails to do so.

------------------------------------------------------------------------------
FIXED  SDSCM00041551
------------------------------------------------------------------------------

Summary            : scanf %d and %f should immediately return upon input
		     failure, even if ordinary characters
		     were matched

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

Description: 
scanf should immediately return when an input failure occurs, even if 
ordinary characters in the format were already successfully matched. 
This bug affects all of the integer and float conversions.

------------------------------------------------------------------------------
FIXED  SDSCM00041552
------------------------------------------------------------------------------

Summary            : sscanf.c _chkmbc should return EOF on input failure

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

Description: 
It should be possible for sscanf to return EOF on a string if an input
error occurs (the end of the input string is reached before the format
string is exhausted), but it does not return EOF as appropriate.

------------------------------------------------------------------------------
FIXED  SDSCM00041553
------------------------------------------------------------------------------

Summary            : scanf input failure when looking for ordinary characters
		     always returns EOF

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

Description: 
When matching ordinary characters in the format string, if there is an
input failure, scanf should return EOF only if there were no previous
successful conversions.  If there were any, it should return the
number of previous successful conversions.

------------------------------------------------------------------------------
FIXED  SDSCM00041554
------------------------------------------------------------------------------

Summary            : scanf %e and %[ should not return EOF on matching failure

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

Description: 
When using %f (or other floating-point conversion specifier) or %[, if
a matching failure occurs before even one character is matched, scanf
will return EOF instead of 0 as the standard requires.


------------------------------------------------------------------------------
10. Current Known Issues
------------------------------------------------------------------------------

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00035379
------------------------------------------------------------------------------

Summary            : C++ requires overloaded abs() and div() in stdlib.h
Affected Component : Runtime Support Libraries (RTS)

Description: 
ISO14882 (C++) 26.5 (C Library) requires overloaded versions of a bunch
of standard C functions.  The floating-point counterpart of abs() was
added to math.h, but we also need "long" versions of abs() and div() in
stdlib.h.  See also SDSCM00028948 and commit #16636.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Description: 
The ARM disassembler errorneously disassembles "VMRS APSR_[bits],
FPSCR" as "VMSR PC, FPSCR".

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

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

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

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00038118
------------------------------------------------------------------------------

Summary            : Pow, powf bug in ARM math library
Affected Component : Runtime Support Libraries (RTS)

Description: 
When the result would be smaller than DBL_MIN (or FLT_MIN for powf), the 
call returns +INF instead of 0.0.  For example, pow(DBL_MIN, DBL_MAX) will 
return +INF. 

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

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

Description: 
The ARM RTS libraries are marked as having no visible enumerations.
This is true for the C library routines, but not the C++. Some C++
header files include inline functions that manipulate enumeration
values.

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

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

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00039420
------------------------------------------------------------------------------

Summary            : Compiler issues unwarranted warning for violation of Misra
		     9.2 for zero initialization of multi
		     dimensional arrays
Affected Component : C/C++ Compiler (cl)

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00039445
------------------------------------------------------------------------------

Summary            : Interrupt functions are pulled in from libraries even if
		     they are not referenced.
Affected Component : Linker

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00039483
------------------------------------------------------------------------------

Summary            : Linker generated CRC tables are not allowed for .cinit in
		     EABI
Affected Component : Linker

Description: 
The linker does not allow linker generated CRC table on the .cinit
output section. This is a bug as it should be supported.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00039492
------------------------------------------------------------------------------

Summary            : Need warning when compiler options conflict with -o4 (LTO)
Affected Component : C/C++ Compiler (cl)

Description: 
Certain compiler options such as -n will terminate the compiler early
which conflicts with the functioning of -o4.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00039600
------------------------------------------------------------------------------

Summary            : Assembler generates error "Register list required" on macro
		     names that begin with 'push' or 'pop'
Affected Component : Assembler

Description: 
The assembler generates the following errors if a macro name that have
contains 'push' or 'pop' at the start of the macro name.

The macro names fail when for ARM7 or CortexR4 targets.    

However the macro names work if CortexM3 is the target.

"forth.asm", ERROR!   at line 4719 [E0004] Register list required
		pushD	tos

"forth.asm", WARNING! at line 4800 [W0004] Invalid instruction
modifier(s)
					    ignored
		popD	tos

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00039838
------------------------------------------------------------------------------

Summary            : Linker should issue error message when it detects a
		     trampoline destination is a load
		     address and not a run address
Affected Component : Linker

Description: 
Branching to a load address is not supported.  When a trampoline is
used to branch to a load address, the linker should issue an error
message and not allow it.  Instead, it issues some confusing warnings.  

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00041124
------------------------------------------------------------------------------

Summary            : Assembler gives error for SUB instruction with PC as
		     operand
Affected Component : Assembler

Description: 
Assembler gives error for SUB instruction with PC as operand

 sub r2, PC, #4

generates [E0004] Specifying R15 as an operand is illegal.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00041308
------------------------------------------------------------------------------

Summary            : Demangler does not expose the --abi=eabi option through the
		     help or compiler documentation
Affected Component : Demangler (dem)

Description: 
The demangler supports --abi=eabi to switch the demangling scheme for
all targets that support EABI. It is currently not documented, nor is
it displayed if --help is given. 

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00041780
------------------------------------------------------------------------------

Summary            : Demangler -h option does not show all the currently
		     available options, such as --abi=eabi
Affected Component : Demangler (dem)

Description: 
The -h option of dem470 does not show all the currently available
options, such as --abi=eabi.  

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00042418
------------------------------------------------------------------------------

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

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00042545
------------------------------------------------------------------------------

Summary            : The raise() function resets the signal handler for the
		     signal type, which is incorrect
Affected Component : Runtime Support Libraries (RTS)

Description: 
The signal() function instates a signal handler for a particular signal
and returns the previous handler. The raise() function uses the
signal() function to determine the current signal handler. In doing so
it replaces the current handler with the default handler. My
understanding of the raise() function is that it is not supposed to
reset the signal handler (GCC handles this appropriately).

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00042699
------------------------------------------------------------------------------

Summary            : Linker Internal Error Crash when compiling with -04 (LTO)
Affected Component : C/C++ Compiler (cl)

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00042764
------------------------------------------------------------------------------

Summary            : The fpclassify macro results in calls to undeclared
		     functions, _Dclass, _FDclass, and _LDclass in C++
Affected Component : Runtime Support Libraries (RTS)

Description: 
The fpclassify function calls these 3 functions to classify a floating
point number. They are declared inside the std namespace and are also
extern "C". Being that they are in the std namespace, the naked call is
not recognized. 

Workaroud:
The problem can be worked around by including the appropriate using 
directives:

using ::std::_Dclass; using ::std::_FDclass; using ::std::_LDclass

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00042973
------------------------------------------------------------------------------

Summary            : ELF loader doesn't zero-initialize difference between "file
		     size" and "mem size"
Affected Component : ELF Linker

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

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

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00043099
------------------------------------------------------------------------------

Summary            : __TI_UNWIND_TABLE_START incorrectly set to -1 when split
		     allocation is attempted on .ARM.exidx
Affected Component : Linker

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00043121
------------------------------------------------------------------------------

Summary            : MISRA C rule 12.9 checking not correct in the TI ARM v4.9.1
		     compiler
Affected Component : C/C++ Compiler (cl)

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00043122
------------------------------------------------------------------------------

Summary            : MISRA C rule 6.4 checking in the TI ARM v4.9.1 compiler not
		     correct
Affected Component : C/C++ Compiler (cl)

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00043187
------------------------------------------------------------------------------

Summary            : ELF e_phoff and e_shoff members of the ELF header pointing 
                     to odd file offsets
Affected Component : ELF Linker

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00043268
------------------------------------------------------------------------------

Summary            : CCS stack backtrace doesn't seem to work across varags
		     function calls
Affected Component : C/C++ Compiler (cl)

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00043502
------------------------------------------------------------------------------

Summary            : packed bit-field leads to internal error
Affected Component : C/C++ Compiler (cl)

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00043543
------------------------------------------------------------------------------

Summary            : The CHECK_MISRA pragma does not have an effect for misra
		     rule 2.2
Affected Component : Parser

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00043752
------------------------------------------------------------------------------

Summary            : Linker ignores input sections in certain cases
Affected Component : C/C++ Compiler (cl)

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00043848
------------------------------------------------------------------------------

Summary            : hex470 output file cannot contain spaces
Affected Component : Hex Converter (hex)

Description: 
While the hex utility accepts spaces on the output file name, it seems
to split the filename and drop everything after the space when actually
creating the output files.

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

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

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00044196
------------------------------------------------------------------------------

Summary            : Message generated during compilation of an unit needs to
		     have source file info
Affected Component : C/C++ Compiler (cl)

Description: 
Misra rule 1.1 needs to include file name in the diagnostic issued.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00044435
------------------------------------------------------------------------------

Summary            : Assembler generates error about symbol defined differently
		     in each pass
Affected Component : Assembler

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00044592
------------------------------------------------------------------------------

Summary            : Request to remove the 130 character width limitation of
		     assembly listing files
Affected Component : Assembler

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00044861
------------------------------------------------------------------------------

Summary            : The ARM assembler accepts several illegal versions of
		     branch instructions
Affected Component : Assembler

Description: 
Examples

ARM mode
BL <register>
B   <register>

Thumb mode
BX <label>
BL <register>
B   <register>

Cortex-M
INTERNAL ERROR for BLX <label>

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00044932
------------------------------------------------------------------------------

Summary            : BLX instruction in assembly file not correctly encoded. 
		     Windows only.  Does not affect compiled C/C++ code.
Affected Component : Assembler

Description: 
Assembler incorrectly encodes a BLX instruction for the attached test
case.  The issue seems specific to Windows executables as the problem
does not manifest on Linux builds.  The test cases is a .asm file that
has a BLX in thumb mode to a destination in ARM mode.  This is not an
issue for C/C++ compiled code.

Using a BLX.N or BLX.W avoids the problem.  Problem reported to be
specific to assembling for 7R4 and 7A8.

Problem also occurs for version 5.0.0

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00045250
------------------------------------------------------------------------------

Summary            : ARM assembler does not correctly handle the SRS instruction
Affected Component : Assembler

Description: 
The assembler parses the SRS instruction with the form SRS <mode>{!}.
The correct instruction is SRS SP{!}, <mode>.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00045257
------------------------------------------------------------------------------

Summary            : strip470 failure
Affected Component : Strip Utility

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00045417
------------------------------------------------------------------------------

Summary            : bool and _Bool are not defined correctly
Affected Component : C/C++ Compiler (cl)

Description: 
The C++ type "bool" and the C99 type "_Bool" should have the same type,
but in the TI toolset they have different sizes, which means that C++
modules which use "bool" are not compatible with C modules which
include stdbool.h and use "bool".

The ARM EABI Procedure Call Standard for the ARM Architecture (ARM IHI
0042D) section 7.1.1 ("Arithmetic Types") requires that both C++ bool
and C99 _Bool be unsigned byte types.  However, the TI toolset does not
conform to that requirement.

For C++ 

The TI compiler defines the builtin type "bool" as plain "char".  This
means it is susceptible to the --plain_char option.  Thus, if the user
uses "--abi=eabi --plain_char=signed", the sign of "bool" will be
incorrect.  This apparently does not affect the correctness of user
programs, but it can cause the compiler to use a less-efficient
sign-extending load for a "bool" object instead of a zero-extending
load.

For C99

The TI compiler does not officially support C99, but does provide the
stdbool.h header file which defines the typedef _Bool and the macro
bool, which is defined to be "_Bool".  This header file incorrectly
defines _Bool to be a typedef for "unsigned int".  This means that C++
modules which use "bool" are not compatible with C modules which
include stdbool.h and use "bool".

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

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

Description: 
Compiler misreports MISRA warning 17.6 with the attached code.

(MISRA-C2004 17.6/R) The address of an object with automatic storage
shall not be assigned to another object that may persist after the
first object has ceased to exist

In the following code, the assignment of &myLocalStruct->data to
myDataPtr in myFunc has MISRA 17.6 reported. myDataPtr only persists
for the duration of the function, and therefore does not persist longer
than data passed into that function.

typedef struct
{
    uint8 data;
} Struct_T;

void myFunc(Struct_T *myLocalStruct);
void main(void);

void myFunc(Struct_T *myLocalStruct)
{
    uint8 *myDataPtr;

    myDataPtr = &myLocalStruct->data; /* (MISRA-C2004 17.6/R) reported
here */
}

void main(void)
{
    Struct_T myStruct = { 0U };

    myFunc(&myStruct);
}


------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00045470
------------------------------------------------------------------------------

Summary            : TMS470 V4.5 and later compiler output .sysmem as
		     initialized section with GROUP command
		     in cmd file
Affected Component : Linker

Description: 
1. TMS470 V4.5 and later compiler output .sysmem as initialized section
with GROUP command in cmd file. if do not include .sysmem into GROUP,
it won't be initialized section.

2. with same project and cmd file, V4.1.5 compiler doesn't output
.sysmem as initialized section. Expect new compiler behave as that of
v4.1.5.

3. test case in attachments. also uploaded to forum in below link
https//e2e.ti.com/support/development_tools/compiler/int-compiler/f/85/
p/764846/reply.aspx?Redirected=true


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

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

Description: 
Compiler misreports violation of Misra 9.2 for zero initialization of
structures.

(MISRA-C2004 9.2/R) Braces shall be used to indicate and match the
structure in the non-zero initialisation of arrays and structures


typedef struct
{
unsigned char nModuleId;
unsigned char nInstanceId;
unsigned char nApiId;
unsigned char nErrorId;
} DetLog_T;

DetLog_T sctDetLog_M[0x100] = { 0U };


------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00045490
------------------------------------------------------------------------------

Summary            : Link Broken in Compiler Reference Manual
Affected Component : Documentation

Description: 
Specifically SPNU151G	hyperlink 
"http//www.arm.com/products/DevTools/ABI.html"
as of 10/02/2012 the link is not working (takes you to ARMs site but
page not found).

Suggestion ->  Put a link to an embedded processor wiki page (TI
controlled) in the doc like this page
http//processors.wiki.ti.com/index.php/A_Brief_History_of_TI_Object_Fil
e_Formats

Section from SPNU151G referred to
5.11.3	 ARM ABIv2 or EABI
The ARM ABIv2 has become an industry standard for the ARM architecture.
It has these advantages

1)    It enables interlinking of objects built with different tool
chains. For example, this enables a library built
with RVCT to be linked in with an application built with the ARM 4.6
toolset.

2)    It is well documented and the documentation is a reference point
for those writing utilities that require
an understanding of the ABI. The complete ARM ABI specifications can be
found at http//www.arm.com/products/DevTools/ABI.html.

3)    It is modern. EABI requires ELF object file format which enables
supporting modern language features
like early template instantiation and export inline functions support.

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00045630
------------------------------------------------------------------------------

Summary            : Should accept and ignore IT instruction in ARM mode
Affected Component : Assembler

Description: 
TI's assembler emits an error upon encountering the IT instruction in
ARM mode.  It should accept it and do nothing.

From the IT instruction description

    The conditions specified in an IT instruction must match those
specified in the syntax of the instructions in its IT block. When
assembling to ARM code, assemblers check IT instruction syntax for
validity but do not generate assembled instructions for them.


------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00046518
------------------------------------------------------------------------------

Summary            : INTERNAL ERROR from linker if crc_table() is specified for
		     an uninitialized section
Affected Component : ELF Linker

Description: 
If a CRC calculation is requested for an uninitialized section, the
linker aborts.	 

------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00046936
------------------------------------------------------------------------------

Summary            : Hex utility incorrectly skips over a section with a
		     duplicate name
Affected Component : Hex Converter (hex)

Description: 
There can be duplicate section names in an ELF file (and possibly a
COFF file).  The hex converter uses the section name as if it were a
unique key when looking up the section in the section table.  For
duplicate section names, it will emit a warning and fail to convert the
section.  This was originally reported as SDSCM00046084, but that
defect has been re-purposed as a more targeted fix that will handle the
user's original test case; the fix for SDSCM00046084 is to ignore
zero-length sections.  Handling duplicate section names, neither of
which are empty, will require some redesign, and we want to make that a
separate effort.


------------------------------------------------------------------------------
KNOWN ISSUE  SDSCM00047500
------------------------------------------------------------------------------

Summary            : Predefined symbol __TI_GNU_ATTRIBUTE_SUPPORT__ not handled
		     as described in documentation
Affected Component : Parser

Description: 
The documentation says ...

    __TI_GNU_ATTRIBUTE_SUPPORT__  Defined if GCC extensions are enabled
(the --gcc option is used); otherwise, it is undefined

However, this symbol is defined regardless of whether --gcc is used. 
Either the documentation or the compiler must be corrected.

