This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Tool/software: TI C/C++ Compiler
Hi all,
I'm looking for known errata / bugs for MSP430 compiler version 4.3.1.
I've been scouring Google and the TI site. The closest I've gotten is this link to "MSP430 Code Generation Tools Downloads" but that starts with version 4.4.8.
Help?
PhilCFN said:I'm looking for known errata / bugs for MSP430 compiler version 4.3.1.
Unfortunately, this is not available for public download. It is attached to the end of this post.
Thanks and regards,
-George
MSP430 C/C++ CODE GENERATION TOOLS
4.3.1 February 2014
Defect History
-------------------------------------------------------------------------------
Table of Contents
-------------------------------------------------------------------------------
1. Defects fixed in MSP430 Code Generation Tools release 4.3.1
2. Defects fixed in MSP430 Code Generation Tools release 4.3.0
3. Defects fixed in MSP430 Code Generation Tools release 4.3.0B1
4. Current Known Issues
===============================================================================
1. Defects fixed in MSP430 Code Generation Tools release 4.3.1
===============================================================================
The following 3 defects were fixed in MSP430 Code Generation Tools release
4.3.1, released February 2014.
-------------------------------------------------------------------------------
FIXED SDSCM00045417
-------------------------------------------------------------------------------
Summary : bool and _Bool are not defined correctly in strict ANSI
C mode
Fixed in : 4.3.1
Severity : S3 - Minor
Affected Component : C/C++ Compiler (cl)
Duplicate Defects : SDSCM00048227, SDSCM00048226
Release Notes:
The size and type of "bool" and "_Bool" must be the same in all modes
so that declarations of the same object in different modules are
compatible. However, in strict ANSI C89 mode, stdbool.h defines _Bool
as "unsigned int," which means a C++ module using bool and a C module
including stdbool.h and using bool are using incompatible types.
_Bool and stdbool.h are C99 features, so a strictly-conforming C89
program does not use them, but the TI compiler provides them as an
extension. This would cause a problem when attempting to mix C++
files and C files which both declare
The ARM EABI Procedure Call Standard for the ARM Architecture (ARM IHI
0042D) section 7.1.1 ("Arithmetic Types") requires that both C++ bool
and C99 _Bool be unsigned byte types. However, the TI toolset does
not conform to that requirement.
Defect occurs in MSP430 Compiler versions: 3.0.0 - 3.0.1, 3.1.0B1 - 3.1.0,
3.2.0B1 - 3.2.3, 3.3.0B1 - 3.3.3, 4.0.0B1 - 4.0.2, 4.1.0B1 - 4.1.8, 4.2.0B1 -
4.2.3, 4.3.0B1 - 4.3.0
Workaround:
The compiler and library now agree on a single definition of bool and
_Bool in all modes; its format is equivalent to "unsigned char."
Unfortunately, this represents a backward incompatibility with older
object files which match all of these conditions:
- C source code
- includes stdbool.h
- compiled in strict C89 mode (the default in older compilers)
- module interface uses type _Bool or bool (i.e. a global variable,
function argument, or function return value of type derived from
bool, or struct containing a type derived from bool.)
To work around the problem, either recompile with the latest version
of the compiler, or ensure that you aren"t using any _Bool or bool
objects in the module interface.
-------------------------------------------------------------------------------
FIXED SDSCM00049271
-------------------------------------------------------------------------------
Summary : INTERNAL ERROR results when building code that uses
features from Google Test C++ testing framework
Fixed in : 4.3.1
Severity : S2 - Major
Affected Component : C/C++ Compiler (cl)
Release Notes:
No Information Available; please see defect details.
Workaround:
declare VAR as "extern const int VAR = 1;"
-------------------------------------------------------------------------------
FIXED SDSCM00049407
-------------------------------------------------------------------------------
Summary : FAILURE in mark_use_of_function_local_static with
--opt_level=4
Fixed in : 4.3.1
Severity : S2 - Major
Affected Component : Optimizer
Duplicate Defects : SDSCM00049409
Release Notes:
In rare cases, the optimizer may emit a spurious diagnostic message
which says "FAILURE in mark_use_of_function_local_static." This
message includes some symbol names, the first of which will be
partially garbled. This message does not affect the generated code,
so it may be ignored.
Defect occurs in MSP430 Compiler versions: 3.3.0B1 - 3.3.3, 4.0.0B1 - 4.0.2,
4.1.0B1 - 4.1.8, 4.2.0B1 - 4.2.0B2, 4.3.0B1 - 4.3.0
Workaround:
Ignore the message "FAILURE in mark_use_of_function_local_static."
===============================================================================
2. Defects fixed in MSP430 Code Generation Tools release 4.3.0
===============================================================================
The following 8 defects were fixed in MSP430 Code Generation Tools release
4.3.0, released January 2014.
-------------------------------------------------------------------------------
FIXED SDSCM00047666
-------------------------------------------------------------------------------
Summary : Definition of SIZE_MAX is wrong
Fixed in : 4.3.0
Severity : S3 - Minor
Affected Component : C/C++ Compiler (cl)
Release Notes:
The definition of SIZE_MAX was incorrectly specified as the largest
signed integer value. It is now defined as the largest unsigned integer
value.
Defect occurs in MSP430 Compiler versions: 3.3.0B1 - 3.3.3, 4.0.0B1 - 4.0.2,
4.1.0B1 - 4.1.8, 4.2.0B1 - 4.2.3, 4.3.0B2 - 4.3.0B1
Workaround:
None.
-------------------------------------------------------------------------------
FIXED SDSCM00048289
-------------------------------------------------------------------------------
Summary : Errors of the linker due to the difference in version of
CGT
Fixed in : 4.3.0
Severity : S2 - Major
Affected Component : Linker
Duplicate Defects : SDSCM00048621
Release Notes:
The fix for SDSCM00044393 was intended to allow the following linker
command file syntax:
SECTIONS
{
OUTSECT_NAME MEMORY_RANGE_NAME
}
The Assembly Language Tools User Guide erroneously stated that this
syntax was accepted. However, allowing the above syntax introduces
ambiguity in the linker command file grammar, which caused previously
accepted command files to produce errors, resulting in this bug
(SDSCM00048289).
This change removes the fix applied for SDSCM00044393. The above syntax
will no longer be accepted. The linker will now issue a warning if an
output section is specified but no placement information is found for
it. The documentation will be updated to specify that load allocation
may be specified with the syntax "load = allocation" or "> allocation".
The above syntax will result in a warning that no placement was specified
for OUTSECT_NAME and a default placement will be applied. Valid linker
command files that were rejected due to the ambiguity will now be accepted.
Workaround:
The problem can be avoided by using memory range names that are different from
section names. For example, this linker command file may cause the error
because "RAM" is both a memory range name and a section name:
MEMORY {
RAM :
}
SECTIONS {
<other section directives>
RAM : > RAM
}
But this one would not cause the error:
MEMORY {
RAM_MEM :
}
SECTIONS {
<other section directives>
RAM : > RAM_MEM
}
Also okay:
MEMORY {
RAM :
}
SECTIONS {
<other section directives>
RAM_SECT : > RAM
}
-------------------------------------------------------------------------------
FIXED SDSCM00048440
-------------------------------------------------------------------------------
Summary : SIGSEGV when using MISRA checks on code with an
anonymous struct
Fixed in : 4.3.0
Severity : S2 - Major
Affected Component : Parser
Release Notes:
When using MISRA checking on code that contains an anonymous struct, the
parser will crash with a SIGSEGV. Note that anonymous structs are not
legal in strict ANSI mode, and MISRA emits a warning if strict ANSI mode
is not used.
Defect occurs in MSP430 Compiler versions: 4.0.0B1 - 4.0.2, 4.1.0B1 - 4.1.8,
4.2.0B1 - 4.2.2, 4.3.0B1
Workaround:
Do not use anonymous structs or unions when using MISRA
-------------------------------------------------------------------------------
FIXED SDSCM00048562
-------------------------------------------------------------------------------
Summary : Use of --small_enum causes linker to not find matching
RTS library
Fixed in : 4.3.0
Severity : S2 - Major
Affected Component : C/C++ Compiler (cl)
Release Notes:
Automatic library generation is now supported for the --small_enum option.
Defect occurs in MSP430 Compiler versions: 4.1.0B1 - 4.1.8, 4.2.0B1 -
4.2.2, 4.3.0B1
Workaround:
Avoid the use of --small_enum or build the library by hand.
-------------------------------------------------------------------------------
FIXED SDSCM00048712
-------------------------------------------------------------------------------
Summary : ARM assembler seg faults on certain input
Fixed in : 4.3.0
Severity : S3 - Minor
Affected Component : Assembler
Release Notes:
The problem is that the assembly instruction LDR r0,0x40004000 is not legal.
The assembler believes 0x40004000 is a symbol because the user did not put a
'#' in front of it. Adding the '#' produces the correct error: "Invalid
addressing mode". This is still a defect because the assembler sshould not seg
fault on a bad instruction.
Workaround:
Add the '#' in front of the 0x40004000 to produce the correct "Invalid
addressing mode" error.
-------------------------------------------------------------------------------
FIXED SDSCM00048747
-------------------------------------------------------------------------------
Summary : Using END(sym_name) or SIZE(sym_name) on .cinit can
cause link to fail
Fixed in : 4.3.0
Severity : S2 - Major
Affected Component : ELF Linker
Release Notes:
When the compression is performed, the size of the parent collection needs to
be updated.
Workaround:
Avoid the use of the END() or SIZE() operators for .cinit or other
compressed sections.
-------------------------------------------------------------------------------
FIXED SDSCM00049035
-------------------------------------------------------------------------------
Summary : Value of "weak" global incorrectly propagated into
function
Fixed in : 4.3.0
Severity : S2 - Major
Affected Component : Optimizer
Release Notes:
When using a weak symbol def with an initializer, the weak symbol could
be pre-empted with a strong symbol from another compilation unit. The
optimizer is not entitled to assume that weak definition is actually
used, and thus cannot assume its initializer is the actual value it has
at runtime. However, the optimizer mistakenly copied the value of the
initializer into the function where the variable was used, which led to
an error when the symbol was pre-empted by a strong symbol with a
different value.
Defect occurs in MSP430 Compiler versions: 4.0.0B1 - 4.0.2, 4.1.0B1 - 4.1.8,
4.2.0B1 - 4.2.3, 4.3.0B2 - 4.3.0B1
Workaround:
Do not use an explicit initializer with weak symbol definitions, or use
optimization level -o2 or lower.
-------------------------------------------------------------------------------
FIXED SDSCM00049206
-------------------------------------------------------------------------------
Summary : #pragma CLINK does not work on initialized data
Fixed in : 4.3.0
Severity : S3 - Minor
Affected Component : C/C++ Compiler (cl)
Release Notes:
The CLINK pragma now works as expected for initialized data.
Defect occurs in MSP430 Compiler versions: 4.2.0B1 - 4.2.3, 4.3.0B2 - 4.3.0B1
Workaround:
Only uninitialized data can be marked CLINK. To make data CLINK, make it
unitialized and do the initialization at startup.
===============================================================================
3. Defects fixed in MSP430 Code Generation Tools release 4.3.0B1
===============================================================================
The following 22 defects were fixed in MSP430 Code Generation Tools release
4.3.0B1, released November 2013.
-------------------------------------------------------------------------------
FIXED SDSCM00013456
-------------------------------------------------------------------------------
Summary : fgets in _IONBF mode does not respect size limit
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : Runtime Support Libraries (RTS)
Release Notes:
The second argument to fgets() is the maximum number of chars to read.
In _IONBF mode, fgets() reads until end-of-line, potentially
overrunning the input buffer. For example:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
main()
{
FILE *f = fopen("tst.txt", "r");
char buffer[100];
int counter = 0;
setvbuf(f, NULL, _IONBF, 0);
while (fgets(buffer, 5, f) != NULL)
{
printf("[%s]\n", buffer);
switch (counter++)
{
case 0: assert(!strcmp(buffer, "aaaa")); break;
case 1: assert(!strcmp(buffer, "bbbb")); break;
case 2: assert(!strcmp(buffer, "cccc")); break;
}
}
assert(feof(f));
puts("PASS");
}
With tst.txt having (with no trailing newline):
aaaabbbbcccc
Defect occurs in MSP430 Compiler versions: 1.0.0B1 - 1.0.1, 2.0.0B1 - 2.0.2,
3.0.0B1 - 3.0.1, 3.1.0B1 - 3.1.0, 3.2.0B1 - 3.2.3, 3.3.0B1 - 3.3.3, 4.0.0B1 -
4.0.2, 4.1.0B1 - 4.1.6, 4.2.0B1 - 4.2.0
Workaround:
Do not use _IONBF mode
-------------------------------------------------------------------------------
FIXED SDSCM00043605
-------------------------------------------------------------------------------
Summary : Linker segfaults linking partially linked file when
partial link includes RTS library, ELF, and exceptions
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : ELF Linker
Release Notes:
This bug will be fixed on C6000 7.5.0, MSP430 4.3.0, and ARM 5.2.0 releases,
and later. The bug will not be fixed on older releases due to technical
difficulties.
Table driven exception handling (TDEH) is not supported during a partial link
where sections are collected into an output section. During a partial link, if
no SECTIONS directive is used, all input sections are passed through as output
sections. In this case TDEH should work fine after the final link. If there is
a SECTIONS directive for the partial link, then TDEH will not work and will
most likely cause an INTERNAL ERROR during the final link.
Workaround:
Do not use a SECTIONS directive when performing a partial link and TDEH
is enabled.
-------------------------------------------------------------------------------
FIXED SDSCM00043860
-------------------------------------------------------------------------------
Summary : Printf format %#06x prints zeros in the wrong place
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : C/C++ Compiler (cl)
Duplicate Defects : SDSCM00008251
Release Notes:
When the # and 0 flags are both used with the x conversion specifier, any
extra 0 characters added to fill up the precision should be added after
the 0x prefix, but the TI library added them before the 0x prefix.
Defect occurs in MSP430 Compiler versions: 2.0.0B1 - 2.0.2, 3.0.0B1 - 3.0.1,
3.1.0B1 - 3.1.0, 3.2.0B1 - 3.2.3, 3.3.0B1 - 3.3.3, 4.0.0B1 - 4.0.2, 4.1.0B1 -
4.1.7, 4.2.0B1 - 4.2.1
Workaround:
Avoid using both # and 0 flags when using the x conversion specifier.
-------------------------------------------------------------------------------
FIXED SDSCM00044118
-------------------------------------------------------------------------------
Summary : Inline jump table mistakenly gets .clink attached
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : Code Generator
Release Notes:
The compiler sometimes generates jump tables to implement switches.
Usually, these jump tables are in a different section, and each
section needs to be handled with the appropriate choice of .retain,
.clink, or neither. In this case, as a special optimization, the jump
table is actually part of the function text, and is not in its own
distinct section. In this case, the compiler should not emit any
.retain or .clink, but it emits .clink. The assembler detects this
and (depending on the ABI) emits a warning that the .clink is ignored.
Defect occurs in MSP430 Compiler versions: 2.0.2, 3.0.0B1 - 3.0.1, 3.1.0B1 -
3.1.0, 3.2.0B1 - 3.2.3, 3.3.0B1 - 3.3.3, 4.0.0B1 - 4.0.2, 4.1.0B1 - 4.1.7,
4.2.0B1 - 4.2.1
Workaround:
You can ignore this warning.
-------------------------------------------------------------------------------
FIXED SDSCM00044121
-------------------------------------------------------------------------------
Summary : Linker option --retain is not displayed in CCS GUI or
when typing cl430 --help
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : ELF Linker
Release Notes:
Linker option --retain is not displayed in the CCS GUI or when typing
cl430 --help
Workaround:
The --retain option is supported even though it does not appear as an
option in CCS or with --help. It can be specified on the command line or in
the CCS dialogue.
-------------------------------------------------------------------------------
FIXED SDSCM00045173
-------------------------------------------------------------------------------
Summary : Missing qsort and bsearch implementations for comparison
functions with C++ linkage
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : C/C++ Compiler (cl)
Release Notes:
The C++ standard requires two distinct prototypes for qsort, one for
comparison functions with C linkage, and one for comparison functions
with C++ linkage. The C++ linkage implementation was missing, which
would lead to an incompatible parameter error when trying to use qsort in
C++ with a comparison function that has C++ linkage.
Defect occurs in MSP430 Compiler versions: 2.0.0B1 - 2.0.2, 3.0.0B1 - 3.0.1,
3.1.0B1 - 3.1.0, 3.2.0B1 - 3.2.3, 3.3.0B1 - 3.3.3, 4.0.0B1 - 4.0.2, 4.1.0B1 -
4.1.5, 4.2.0B1
Workaround:
Declare the comparison function extern "C"
-------------------------------------------------------------------------------
FIXED SDSCM00045373
-------------------------------------------------------------------------------
Summary : EXIDX section for alias function leads to INTERNAL ERROR
unhandled exception
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : Linker
Release Notes:
If all of --exceptions, --unused_section_elimination=off, and
--retain=.ARM.EXIDX are used, and the compiler turns a C++ function into
an alias (this is a TI-specific optimization), it is possible for the
linker to retain the EXIDX section for the alias function but not the
alias function itself, which leads to an internal error.
Defect occurs in MSP430 Compiler versions: 4.0.0B1 - 4.0.2, 4.1.0B1 - 4.1.5,
4.2.0B1 - 4.2.0B2
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 SDSCM00045923
-------------------------------------------------------------------------------
Summary : Compiling with --small_enum and -o4 (linktime
optimization) results in errors about incompatible
--enum_type settings
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : COFF Linker
Release Notes:
The compiler option --small_enum allows the compiler to use a small container,
such as char or short, if the enum type will fit. Previous versions of the
compiler did not properly detect inconsistency in the enum sizes between
files. These changes attempt to detect incompatibility at link time, while
not placing undue restrictions on users.
a.) The compiler will detect an enum size inconsistency if the input source
uses enum types. If an inconsistency is found, the compiler will issue a
warning. It is possible that the code could be correct and functional if
the warning is issued. It is ultimately the user's responsibility to
ensure that enums are used correctly.
b.) Assembly source code and object files created by previous versions of
the compiler will be compiled with an unknown enum size. Object files
with unknown enum size are treated as universally compatible. Again, the
user is ultimately responsible.
c.) The use of --small_enum will not result in the automatic build of a
compatible RTS library. The user must build a small enum RTS if necessary.
Instructions can be found at http://processors.wiki.ti.com/index.php/Mklib
in the section Building libraries with custom options.
d.) The use of libc.a with --small_enum may fail to find a compatible
library during linking if enums are used. If a custom RTS is not required,
the user may name a specific library, which should allow a successful link
with a warning.
e.) The use of --small_enum with C++ RTS packages that expose enum types,
such as iostream, will result in incorrect code if the RTS uses the default
enum size. The warning will be issued. In this case, a compilation using
"-o4" may also fail with a type incompatibility error. All of the supplied
RTS libraries use the default enum size.
f.) The use of the gcc packed attribute for user-defined enum types is an
alternative to --small_enum.
Workaround:
Use the gcc packed attribute for user-defined enum types.
-------------------------------------------------------------------------------
FIXED SDSCM00046084
-------------------------------------------------------------------------------
Summary : Hex utility incorrectly picks empty section over a
non-empty section with duplicate name
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : C/C++ Compiler (cl)
Release Notes:
There can be duplicate section names in an object file. When
converting such a file, the hex converter will emit a warning and fail
to convert the section. For this test case, it is sufficient to have
the hex converter ignore zero-length sections. Handling duplicate
section names, neither of which are empty, will require some redesign,
and will be pursued as a separate effort. This defect report has been
re-purposed as the more targeted fix of ignoring zero-length sections.
See SDSCM00046936 for the ongoing work to handle duplicate section
names for non-empty sections.
Defect occurs in MSP430 Compiler versions: 4.0.0B1 - 4.0.2, 4.1.0B1 - 4.1.5,
4.2.0B1 - 4.2.0B2
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.3.0B1
Severity : S2 - Major
Affected Component : C/C++ Compiler (cl)
Release Notes:
I conclude that the linker is generating something wrong when creating
relocatable output that gets corrected when it later generates executable
output. A further observation: after linking the relocatable linker
output to form an executable, I note that the section headers are
misaligned (at offset 0xaca from the start of the file).
This appears to break the alignment rule from:
http://www.sco.com/developers/gabi/2003-12-17/ch4.intro.html#file_format
"All data structures that the object file format defines follow the
``natural'' size and alignment guidelines for the relevant class. If
necessary, data structures contain explicit padding to ensure 8-byte
alignment for 8-byte objects, 4-byte alignment for 4-byte objects, to
force structure sizes to a multiple of 4 or 8, and so forth. Data also
have suitable alignment from the beginning of the file. Thus, for
example, a structure containing an Elf32_Addr member will be aligned on a
4-byte boundary within the file. " Section headers contain Elf32_Addr
members, and so should be aligned on a 4-byte boundary (which 0xaca
isn't). It appears that the compiler is failing to pad the size of the
string table to ensure the alignment of the following areas. You can see
that the alignment of the section headers depends on the size of the
string table by changing the function name to 'main2'. This generates an
output file where the section header offset is 534. The misaligned
section headers lead to a CCS crash (SDSCM00046176).
Defect occurs in MSP430 Compiler versions: 4.0.0 - 4.0.2, 4.1.0B1 - 4.1.5,
4.2.0B1 - 4.2.0B2
Workaround:
None.
-------------------------------------------------------------------------------
FIXED SDSCM00046231
-------------------------------------------------------------------------------
Summary : DATA_ALIGN should not be able to reduce alignment below
default array alignment
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : C/C++ Compiler (cl)
Release Notes:
With the following program:
#pragma DATA_SECTION(array, 4)
int array[100];
Observe that the alignment of array is 32, should be 64.
The DATA_ALIGN pragma should not cause an array to have an
alignment that is less than the default array alignment. The DATA_ALIGN
pragma is ignored if it attempts to do so.
Workaround:
Use the DATA_ALIGN pragma with an array alignment value of at least 8 for
C64x+
-------------------------------------------------------------------------------
FIXED SDSCM00046800
-------------------------------------------------------------------------------
Summary : Internal error: no match for 64-bit to 8-bit narrowing
conversion
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : Code Generator
Duplicate Defects : SDSCM00048496, SDSCM00045996
Release Notes:
When converting directly from a 64-bit integer value to an 8-bit
integer type, the compiler can crash with an internal error resembling
"INTERNAL ERROR: no match". Even if the source code doesn't directly
perform such a conversion, the optimizer can create this situation by
simplifying intermediate conversions.
Defect occurs in MSP430 Compiler versions: 4.0.0B1 - 4.0.2, 4.1.0B1 - 4.1.5,
4.2.0B1 - 4.2.0B2
Workaround:
Add a volatile int variable, assign the 64-bit value to that, and then
assign that to the final 8-bit variable.
char workaround(long long x)
{
volatile int y = (int)x;
return (char)y;
}
-------------------------------------------------------------------------------
FIXED SDSCM00046812
-------------------------------------------------------------------------------
Summary : Instructions are placed in the wrong order
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : C/C++ Compiler (cl)
Release Notes:
In rare cases, incorrect analysis by the compiler may indicate that two
memory or stack accesses are unrelated when they actually refer to the
same object. If this occurs, the compiler may schedule an access
incorrectly.
Defect occurs in MSP430 Compiler versions: 4.1.0B1 - 4.1.5, 4.2.0B1 - 4.2.0B2
Workaround:
No definite workaround exists. However, changing the optimization level
may avoid the problem by changing the stack or memory layout.
-------------------------------------------------------------------------------
FIXED SDSCM00046816
-------------------------------------------------------------------------------
Summary : Excessive compile time - Optimizer hangs
Fixed in : 4.3.0B1
Severity : S2 - Major
Classification : Performance
Affected Component : Optimizer
Release Notes:
A program containing large structs containing many fields, especially if
those fields are of type char, may require excessive time to compile.
The compiler must check all those fields for potential aliases, and does
so inefficiently.
Defect occurs in MSP430 Compiler versions: 2.0.0B1 - 2.0.2, 3.0.0B1 - 3.0.1,
3.1.0B1 - 3.1.0, 3.2.0B1 - 3.2.3, 3.3.0B1 - 3.3.3, 4.0.0B1 - 4.0.2, 4.1.0B1 -
4.1.5, 4.2.0B1 - 4.2.0B2
Workaround:
None known.
-------------------------------------------------------------------------------
FIXED SDSCM00046848
-------------------------------------------------------------------------------
Summary : NOINIT keyword may be ignored
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : ELF Linker
Duplicate Defects : SDSCM00047211
Release Notes:
The linker command file keyword type(NOINIT) will be ignored in the ARM
v5.0.4 and MSP430 v4.1.5 compilers. The changes made to fix
SDSCM00045211 were incorrect, causing sections marked NOINIT in the
linker command file to be initialized via the cinit mechanism for EABI.
Defect occurs in MSP430 Compiler versions: 4.1.5, 4.2.0B1 - 4.2.0B2
Workaround:
None.
-------------------------------------------------------------------------------
FIXED SDSCM00046849
-------------------------------------------------------------------------------
Summary : stdin stdout stderr macros need to be usable without
using namespace std for _ftable
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : Runtime Support Libraries (RTS)
Duplicate Defects : SDSCM00045792, SDSCM00043348
Release Notes:
stdin, stdout, and stderr are macros involving the identifier
std::_ftable. As a macro, the namespace is not specified as you would
for a type or variable (std::size_t). When cstdio is included, these
macros are defined and should be usable without a using declaration
putting std::_ftable in the global namespace.
Defect occurs in MSP430 Compiler versions: 2.0.0B1 - 2.0.2, 3.0.0B1 - 3.0.1,
3.1.0B1 - 3.1.0, 3.2.0B1 - 3.2.3, 3.3.0B1 - 3.3.3, 4.0.0B1 - 4.0.2, 4.1.0B1 -
4.1.5, 4.2.0B1 - 4.2.0B2
Workaround:
Include stdio.h instead of cstdio
-------------------------------------------------------------------------------
FIXED SDSCM00046910
-------------------------------------------------------------------------------
Summary : Using an invalid option with valid hex command file
causes SIGSEGV
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : Hex Converter (hex)
Release Notes:
Using an invalid option with valid hex command file causes a
segmentation fault.
Defect occurs in MSP430 Compiler versions: 3.2.0B1 - 3.2.3, 3.3.0B1 - 3.3.3,
4.0.0B1 - 4.0.2, 4.1.0B1 - 4.1.5, 4.2.0B1 - 4.2.0B2
Workaround:
Fix or eliminate the invalid option.
-------------------------------------------------------------------------------
FIXED SDSCM00047206
-------------------------------------------------------------------------------
Summary : Calls to isnan in C++ program lead to undefined symbol
error
Fixed in : 4.3.0B1
Severity : S1 - Critical / PS
Affected Component : Runtime Support Libraries (RTS)
Release Notes:
The definition of isnan and isinf in the header file math.h eventually
refers to library functions, and in C++ needs to refer to these functions
in a namespace. The user should be able to use isnan and isinfo without
refering to the std namespace.
Defect occurs in MSP430 Compiler versions: 4.0.0B1 - 4.0.2, 4.1.0B1 - 4.1.5,
4.2.0B1 - 4.2.0B2
Workaround:
Add "using namespace std;" after including math.h
-------------------------------------------------------------------------------
FIXED SDSCM00047502
-------------------------------------------------------------------------------
Summary : linker fails with internal error if .cinit and .data are
in the same GROUP
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : Linker
Release Notes:
The internal error was caused by attempting to place .cinit in a GROUP
with .data in an ELF file. This is not a recommended practice. The fix
will allow .cinit and .data in a GROUP only if .data preceeds .cinit. In
that case, compression of cinit records can not be performed. If .cinit
is placed before .data in a GROUP, a user level error is reported.
Defect occurs in MSP430 Compiler versions: 4.0.0B1 - 4.0.2, 4.1.0B1 - 4.1.7,
4.2.0B1 - 4.2.1
Workaround:
Move .cinit so that it is not in any GROUP
-------------------------------------------------------------------------------
FIXED SDSCM00047510
-------------------------------------------------------------------------------
Summary : (short)labs(x) incorrectly transformed to abs((short)x)
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : Code Generator
Release Notes:
The compiler tries to change labs to the less-expensive abs when the
result will be cast to the narrower type, anyway. However, this is not
legal unless the input to labs can be represented exactly in type short,
which is not always the case. For example, consider (unsigned
short)labs(40000), which should have the value 40000.
Defect occurs in MSP430 Compiler versions: 2.0.0B1 - 2.0.2, 3.0.0B1 - 3.0.1,
3.1.0B1 - 3.1.0, 3.2.0B1 - 3.2.3, 3.3.0B1 - 3.3.3, 4.0.0B1 - 4.0.2, 4.1.0B1 -
4.1.7, 4.2.0B1 - 4.2.1
Workaround:
Assign the return value of labs to a volatile local variable before
converting it to the narrower type.
-------------------------------------------------------------------------------
FIXED SDSCM00047883
-------------------------------------------------------------------------------
Summary : bsearch failure when using -pr relaxed ANSI mode or
--gcc mode from C++
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : C/C++ Compiler (cl)
Duplicate Defects : SDSCM00047268
Release Notes:
In relaxed mode calling bsearch from C++ results in an infinite loop.
Workaround:
A workaround is to use --strict_ansi.
-------------------------------------------------------------------------------
FIXED SDSCM00048164
-------------------------------------------------------------------------------
Summary : Invalid debug info generated for symbols in
non-consecutive register pairs
Fixed in : 4.3.0B1
Severity : S2 - Major
Affected Component : Code Generator
Release Notes:
32 and 64-bit symbols that are stored in non-consecutive registers will
now be properly displayed when debugging.
Defect occurs in MSP430 Compiler versions: 4.2.0 - 4.2.1
Workaround:
Lowering the optimization level will improve the quality of debug
information.
===============================================================================
4. Current Known Issues
===============================================================================
The following 24 known issues exist for MSP430 Code Generation Tools release
4.3.1 as of February 2014.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00008248
-------------------------------------------------------------------------------
Summary : Compilers on PC will not work without TMP set
Affected Component : C/C++ Compiler (cl)
Duplicate Defects : SDSCM00034609
Description:
When compiling on the PC, the code generator cannot find the icode
file produced by the parser if the environment variable TMP is no
set. If TMP is set, then all appears well.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00008465
-------------------------------------------------------------------------------
Summary : Language Conformance: crash because of void pointer
dereference
Affected Component : Parser
Description:
Compiler generates multiple INTERNAL ERRORs when code like the following
is compiled:
void dr106_1(void *pv, int i)
{
*pv;
i ? *pv : *pv;
*pv, *pv;
}
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00008537
-------------------------------------------------------------------------------
Summary : assembler expression ~(0x80000000) evaulates as
0x80000000
Affected Component : Assembler
Description:
The following expression is evaluating incorrectly in the assembler:
.eval ~(0x80000000), mask
mask ends up getting assigned 0x80000000, whereas I expect it to be
0x7FFFFFFF. It
seems that any constant with bit 31 set will incorrectly return 0x80000000
See internal notes for the original detailed description.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00008543
-------------------------------------------------------------------------------
Summary : Forward reference in .space generates an internal error
Affected Component : Assembler
Description:
If you attempt to assemble:
.space 0+a
b
a .set 1
the assembler will generate an internal error.
This happens with v3.83 and v4.1.0B1 on Solaris.
If you change the code to:
.space a
b
b .set 1
the correct error message is generated, 'Absolute, well-defined integer value
expected'.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00008652
-------------------------------------------------------------------------------
Summary : pow(2,x) has fairly significant rounding error
Affected Component : Runtime Support Libraries (RTS)
Description:
The algorithm used for pow [exp(log(x),y)] is correct but sometimes leads
to a precision error for some inputs, due to rounding bugs in floating-
point handling.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00008928
-------------------------------------------------------------------------------
Summary : Extern inline functions are not supported in the C/C++
Compiler
Affected Component : Parser
Duplicate Defects : SDSCM00018364
Description:
Users cannot create global accessible code with INLINE functions.
The V3.00 compiler/code generator does not create globally accessible
code for functions which are declared inline. A simple example is:
inline int x() { return 1; }
int y() {return 2;}
When compiled with 'cl6x -k -c test.c', a warning is produced:
'test.c', line 1: warning: function 'x' was declared but
never referenced
and the resulting assembler file (test.asm) does not
contain any code for x(). The documentation states that code
declared inline will be inlined in that module but global code will
also be generated (section 2.10.3.2 in v3.00 C Compiler manual). The
new compiler is overly aggressive in its optimizations. If y() is
modified to call x() then code is generated for x() unless the
optimizer is also invoked (by using -x2).
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00014430
-------------------------------------------------------------------------------
Summary : calloc doesn't check arguments to make sure the
requested size is reasonable
Affected Component : Runtime Support Libraries (RTS)
Description:
The function calloc() is required to return a pointer to memory representing
"nelem" copies of "size" bytes, or NULL if the request cannot be satisfied.
However, for some values of "nelem" and "size" (specifically when the result
of nelem*size wraps around), calloc can return a pointer to an object that is
not large enough, rather than NULL.
For example, on a 32-bit target, if the user calls calloc(0x00010001,
0x00010001), even though each argument by itself is reasonable, the request
cannot be satisfied because the product is 0x000100020001, which exceeds
size_t. (Note that we cannot check for overflow by checking if the product is
less than either argument, which is commonly done for unsigned addition.)
Arguably, we can try to claim that it is undefined behavior to make a call to
calloc where the product would exceed size_t, but I don't see anything in the
standard which says so.
The problem is worse on 16-bit targets, where calloc(0x0101, 0x0101) is enough
to overflow size_t. It may not be obvious to the user that this overflows.
Another trouble is that it is hard to figure out whether a multiplication will
overflow without having a double-width multiply available.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00018691
-------------------------------------------------------------------------------
Summary : Linker gives misleading warning when dot expressions
used in SECTION directive for .stack section
Affected Component : Linker
Description:
Linker gives the warning:
warning: creating ".stack" section with default size of 0x800; use the -stack
option to change the default size
even when the application does not link in boot code from RTS lib.
A linker command file is used that contains a specialized SECTION directive
for the ".stack" section. Because of a series of ". += <number>" assignments
in the section spec, the linker is forced to increase the size of the .stack
section to 0xc00. The linker is doing the correct thing by making a .stack
section large enough to accommodate the dot expressions, but the diagnostic is
misleading, as 0x800 isn't the final size of the .stack section.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00038178
-------------------------------------------------------------------------------
Summary : Should forbid non-const objects larger than 64k in large
model if --near_data=globals
Affected Component : C/C++ Compiler (cl)
Description:
In --near_data=globals mode (the default for large data model), it's not
possible to create a non-const object larger than 64k, even in large data
model. The compiler will accept it without error, but at link time there can
be a mysterious relocation overflow, or if there is no link error, the test
case can fail at execution time. It would be far better to catch this earlier
and generate an error message saying "In --near_data=globals mode, non-const
objects larger than 64k are illegal even in large model."
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00038293
-------------------------------------------------------------------------------
Summary : Relocation overflows for BIT instruction using 20-bit
pointer
Affected Component : C/C++ Compiler (cl)
Description:
When using options "cl430 -vmspx --data_model=large --near_data=globals", the
compiler uses a BIT.W instruction to test a 20-bit address, leading to a
relocation overflow. This bug does not happen if --near_data=none (the
compiler uses BITX.W).
The compiler should either use a BITX.W instruction to test expression which
involve pointer addresses, or use a relocation that ignores overflow.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00039054
-------------------------------------------------------------------------------
Summary : Compiler reports a violation of Misra rule 12.8 for a
structure variable
Affected Component : C/C++ Compiler (cl)
Description:
MISRA warning (MISRA-C:2004 12.8/R) The right-hand operand of a shift operator
shall lie between zero and one less than the width in bits of the underlying
type of the left-hand operand
In the following code I get MISRA 12.8 warning on myVar = myStruct.aVar >> 16
shift. Note that shift of unstructured variable myVar = myVar >> 16 is okay.
typedef struct
{
unsigned long aVar;
} myStruct_T;
myStruct_T myStruct = {0xFFFFFFFFUL};
unsigned long myVar;
myVar = myStruct.aVar >> 16;
myVar = myVar >> 16;
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00039236
-------------------------------------------------------------------------------
Summary : Sometimes MISRA rule 19.15 is incorrectly emitted. The
rule is about failing to use an inclusion guard in a
header file.
Affected Component : Parser
Description:
In the attached test case rule 19.15 gets emitted even though the files
mentioned do have proper inclusion guards.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00040934
-------------------------------------------------------------------------------
Summary : Structure is not initialized correctly when using -o2 or
-o3 optimization
Affected Component : Optimizer
Description:
There is a problem with the initialization of a structure using symbols
generated in the linker command file. We use symbols generated in the linker
cmd file using the dot operator. These symbols are used as an initial value
for a class/struct with a constructor. In our case we want the difference of
two addresses that the linker generates.
When using optimization -o2 or -o3, the compiler generates .cinit entries
instead of the constructor call. In those .init-entries it doesn't use the
difference of the addresses; instead it uses the first symbol.
When turning off optimization or using lower level of opt than -o2, the
constructor calls are generated and the struct is initialized correctly.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00042344
-------------------------------------------------------------------------------
Summary : Compiler generates internal error: illegal
initialization or segmentation fault
Affected Component : C/C++ Compiler (cl)
Description:
The attached test case generates a segmentation fault when compiled with CGT
6.1.x and 7.0.x.
It generates the following error when compiled with 7.2.5 and 7.3.1 but does
generate a .obj file.
Build with: cl6x --gcc seg_fault.c
>> INTERNAL ERROR: ILLEGAL INITIALIZATION
This may be a serious problem. Please contact customer support with a
description of this problem and a sample of the source files that caused this
INTERNAL ERROR message to appear.
Note: May lose variable initialization information
... continuing compilation ...
User would like to know if there is a workaround.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00042434
-------------------------------------------------------------------------------
Summary : Compiler misreports Misra warning 6.4 for bitfield
definitions
Affected Component : C/C++ Compiler (cl)
Duplicate Defects : SDSCM00043122
Description:
Compiler misreports Misra warning 6.4 for bitfield definitions.
typedef unsigned int uint16_t;
typedef unsigned int bool_t;
#define FALSE ((bool_t)0U)
#define TRUE ((bool_t)1U)
typedef struct mystructtag
{
uint16_t u16_hw_rev1;
bool_t bl_hardware_supported:1; /* this violates rule 6.4 */
} st_software_info_t ;
This generates the warning:
"misra_test.c", line 9: warning: (MISRA-C:2004 6.4/R) Bit fields shall only be
defined to be of type unsigned int or signed int
Related forum thread:
http://e2e.ti.com/support/development_tools/compiler/f/343/t/147639.aspx
According to Misra, this is not a Misra violation.
http://www.misra-
c.com/forum/viewtopic.php?f=62&t=1167&sid=6fd53ec7591d33a4fa1b38e975c580bc
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00042435
-------------------------------------------------------------------------------
Summary : Compiler misreports Misra warning 10.1
Affected Component : C/C++ Compiler (cl)
Description:
Compiler misreports Misra warning 10.1 with the following code:
typedef unsigned int uint16_t;
typedef unsigned int bool_t;
#define FALSE ((bool_t)0U)
#define TRUE ((bool_t)1U)
typedef struct mystructtag
{
uint16_t u16_hw_rev1;
bool_t bl_hardware_supported:1; /* this violates rule 6.4 */
} st_software_info_t ;
void main(void)
{
uint16_t u16_rev1_min, u16_tmp;
st_software_info_t sts_sw_info;
u16_rev1_min = 900U;
sts_sw_info.bl_hardware_supported = FALSE;
if (sts_sw_info.bl_hardware_supported == FALSE) /* this violates rule 10.1 */
{
/* do something... */
}
if (sts_sw_info.u16_hw_rev1 >= u16_rev1_min) /* this violates rule 10.1 */
{
/* do something... */
}
u16_tmp = sts_sw_info.u16_hw_rev1;
if (u16_tmp >= u16_rev1_min) /* this does not violates rule 10.1 */
{
/* do something... */
}
The warning is:
"misra_test.c", line 22: warning: (MISRA-C:2004 10.1/R) The value of an
expression of integer type shall not be implicitly converted to a different
underlying type if it is not a conversion to a wider integer type of the same
signedness
"misra_test.c", line 27: warning: (MISRA-C:2004 10.1/R) The value of an
expression of integer type shall not be implicitly converted to a different
underlying type if it is not a conversion to a wider integer type of the same
signedness
Related forum thread:http://e2e.ti.com/support/development_tools/compiler/f/3-
43/t/147639.aspx
Related Misra threads that say this is not a Misra violation:
http://www.misra-
c.com/forum/viewtopic.php?f=62&t=1167&sid=6fd53ec7591d33a4fa1b38e975c580bc
http://www.misra-
c.com/forum/viewtopic.php?f=66&t=1168&sid=6fd53ec7591d33a4fa1b38e975c580bc
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00042600
-------------------------------------------------------------------------------
Summary : Ill advised enum scalar usage gets MISRA diagnostic, but
similar usage of enum array does not
Affected Component : C/C++ Compiler (cl)
Description:
The test case given assigned a integer to an enum scalar variable. MISRA
checking correctly flags this with a diagnostic. The test case goes on to do
the same thing with an enum array expression. It should get the same MISRA
diagnostic, but does not.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00043043
-------------------------------------------------------------------------------
Summary : Array that is correctly initialized erroneously gets a
MISRA diagnostic about size not being specified
Affected Component : C/C++ Compiler (cl)
Description:
For this input ...
int16_t y[]={1,5,8};
The compiler incorrectly issues this diagnostic ...
"try1.c", line 2: warning: (MISRA-C:2004 8.12/R) When an array is declared
with external linkage, its size shall be stated explicitly or
defined implicitly by initialisation
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00044056
-------------------------------------------------------------------------------
Summary : Compiler misreports Misra warning 10.1
Affected Component : C/C++ Compiler (cl)
Description:
Compiler misreports MISRA warning 10.1/R for the following code.
typedef enum _MyEnum { One, Two } MyEnum;
MyEnum MyVariable;
int foo(void)
{
int result = 1;
if (One == MyVariable) // fails here with MISRA-C:2004 10.1/R
{ result = 2; }
return result;
}
Our coding style convention requires that the variable is at the right hand
side. Therefore I don't want to swap One and MyVariable, although that makes
the warning to disappear.
Is that a bug in the MISRA checker? If not, why is the comparison of two terms
not commutable?
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00045452
-------------------------------------------------------------------------------
Summary : Compiler misreports MISRA warning 17.6
Affected Component : C/C++ Compiler (cl)
Description:
Compiler misreports MISRA warning 17.6 with the attached code.
(MISRA-C:2004 17.6/R) The address of an object with automatic storage shall
not be assigned to another object that may persist after the first object has
ceased to exist
In the following code, the assignment of &myLocalStruct->data to myDataPtr in
myFunc has MISRA 17.6 reported. myDataPtr only persists for the duration of
the function, and therefore does not persist longer than data passed into
that function.
typedef struct
{
uint8 data;
} Struct_T;
void myFunc(Struct_T *myLocalStruct);
void main(void);
void myFunc(Struct_T *myLocalStruct)
{
uint8 *myDataPtr;
myDataPtr = &myLocalStruct->data; /* (MISRA-C:2004 17.6/R) reported here */
}
void main(void)
{
Struct_T myStruct = { 0U };
myFunc(&myStruct);
}
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00045473
-------------------------------------------------------------------------------
Summary : Compiler misreports violation of Misra 9.2 for zero
initialization of structures
Affected Component : C/C++ Compiler (cl)
Description:
Compiler misreports violation of Misra 9.2 for zero initialization of
structures.
(MISRA-C:2004 9.2/R) Braces shall be used to indicate and match the structure
in the non-zero initialisation of arrays and structures
typedef struct
{
unsigned char nModuleId;
unsigned char nInstanceId;
unsigned char nApiId;
unsigned char nErrorId;
} DetLog_T;
DetLog_T sctDetLog_M[0x100] = { 0U };
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00046851
-------------------------------------------------------------------------------
Summary : Procedure abstraction can mess up TDEH tables
Affected Component : Code Generator
Description:
When procedure abstraction occurs, it seems it can create a corrupted EXIDX
table for the function.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00047833
-------------------------------------------------------------------------------
Summary : msp C++ cpp compiled with printf_support=minimal causes
cout to output incorrect results
Affected Component : Linker
Description:
msp C++ cpp compiled with printf_support=minimal causes cout to output
incorrect results
And from further testing I found that -printf_support=minimal causes incorrect
output from cout (prints out d instead of 1). I submitted CQ47833 for that
since I think we have printf_support=minimal as default for CCS projects.
Another solution to the printf_support=minimal would be to create an CCS
project entry for new C++ project (we only have C code) and that project could
have printf_support option left out. Not including printf_support, or choosing
printf_support=nofloat and full both work.
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00049284
-------------------------------------------------------------------------------
Summary : Compiler misreports Misra warning 10.1
Affected Component : Parser
Description:
Compiler misreports MISRA warning 10.1/R for the following code.
typedef enum _MyEnum { One, Two } MyEnum;
MyEnum MyVariable;
int foo(void)
{
int result = 1;
if (One == MyVariable) // fails here with MISRA-C:2004 10.1/R
{ result = 2; }
return result;
}
Our coding style convention requires that the variable is at the right hand
side. Therefore I don't want to swap One and MyVariable, although that makes
the warning to disappear.
Is that a bug in the MISRA checker? If not, why is the comparison of two terms
not commutable?
