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 { RAM : > RAM } But this one would not cause the error: MEMORY { RAM_MEM : } SECTIONS { RAM : > RAM_MEM } Also okay: MEMORY { RAM : } SECTIONS { 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 #include #include #include 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 ". += " 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?