TMS470 C/C++ CODE GENERATION TOOLS 16.9.0.LTS September 2016 Defect History ------------------------------------------------------------------------------- Table of Contents ------------------------------------------------------------------------------- 1. Defects fixed in TMS470 Code Generation Tools release 16.9.0.LTS 2. Current Known Issues =============================================================================== 1. Defects fixed in TMS470 Code Generation Tools release 16.9.0.LTS =============================================================================== The following 2 defects were fixed in TMS470 Code Generation Tools release 16.9.0.LTS, released September 2016. ------------------------------------------------------------------------------- FIXED CODEGEN-1274 ------------------------------------------------------------------------------- Summary : Assembler incorrectly issues error message: Address must be of a non-global defined in the current section. Fixed in : 16.9.0.LTS Severity : S2 - Major Affected Component : Assembler Release Notes: The attached test case has this line ... ldr r0, ti_sysbios_family_arm_ducati_Core_core1WaitFlag That symbol is defined in the same section as ... ti_sysbios_family_arm_ducati_Core_core1WaitFlag: .word 0 The test case builds clean with version 15.12.1.LTS. But with 16.3.0.STS you see ... "try1.asm", ERROR! at line 44: [E0001] Address must be of a non-global defined in the current section Workaround: Alter the code such that the target label is a non-global symbol defined in the same section as the branch. If the symbol must be global, add a second non-global label such as fake_label and change the branch to "B fake_label". ------------------------------------------------------------------------------- FIXED CODEGEN-1333 ------------------------------------------------------------------------------- Summary : Structure assignment causes compiler to fail with INTERNAL ERROR: Decomposition error. Fixed in : 16.9.0.LTS Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Structure assignment causes compiler to fail with INTERNAL ERROR: Decomposition error. Workaround: Replace struct assignments involving packed structures with a memcpy() call to dpy the contents of the RHS of the struct assign to the LHS. =============================================================================== 2. Current Known Issues =============================================================================== The following 60 known issues exist for TMS470 Code Generation Tools release 16.9.0.LTS as of September 2016. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008248 ------------------------------------------------------------------------------- Summary : Compilers on PC will not work without TMP set Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00034609 Description: When compiling on the PC, the code generator cannot find the icode file produced by the parser if the environment variable TMP is no set. If TMP is set, then all appears well. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008465 ------------------------------------------------------------------------------- Summary : Language Conformance: crash because of void pointer dereference Affected Component : Parser Description: Compiler generates multiple INTERNAL ERRORs when code like the following is compiled: void dr106_1(void *pv, int i) { *pv; i ? *pv : *pv; *pv, *pv; } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008534 ------------------------------------------------------------------------------- Summary : Linker -xml_link_info option doesn't work when in a command file Affected Component : Linker Description: The option --xml_link_info=file.xml does not work when it is placed inside a linker command file. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008537 ------------------------------------------------------------------------------- Summary : assembler expression ~(0x80000000) evaulates as 0x80000000 Affected Component : Assembler Description: The following expression is evaluating incorrectly in the assembler: .eval ~(0x80000000), mask mask ends up getting assigned 0x80000000, whereas I expect it to be 0x7FFFFFFF. It seems that any constant with bit 31 set will incorrectly return 0x80000000 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008543 ------------------------------------------------------------------------------- Summary : Forward reference in .space generates an internal error Affected Component : Assembler Description: If you attempt to assemble: .space 0+a b a .set 1 the assembler will generate an internal error. This happens with v3.83 and v4.1.0B1 on Solaris. If you change the code to: .space a b b .set 1 the correct error message is generated, 'Absolute, well-defined integer value expected'. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008685 ------------------------------------------------------------------------------- Summary : DWARF does not correctly represent variables stored in register pairs Affected Component : Code Generator Description: In the attached example, variables 'var1' and 'var2' are both long long types, and are stored in A7:A6 and B5:B4. However, the DWARF information shows var1 only to be in A6, and var2 only to be in B4: [000000e8] DW_TAG_variable DW_AT_name var1 DW_AT_symbol_name _var1 DW_AT_type [00000113] DW_AT_location { DW_OP_reg6 } [000000fa] DW_TAG_variable DW_AT_name var2 DW_AT_symbol_name _var2 DW_AT_type [00000113] DW_AT_location { DW_OP_reg20 } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008928 ------------------------------------------------------------------------------- Summary : Extern inline functions are not supported in the C/C++ Compiler Affected Component : Parser Duplicate Defects : SDSCM00018364 Description: Users cannot create global accessible code with INLINE functions. The V3.00 compiler/code generator does not create globally accessible code for functions which are declared inline. A simple example is: inline int x() { return 1; } int y() {return 2;} When compiled with 'cl6x -k -c test.c', a warning is produced: 'test.c', line 1: warning: function 'x' was declared but never referenced and the resulting assembler file (test.asm) does not contain any code for x(). The documentation states that code declared inline will be inlined in that module but global code will also be generated (section 2.10.3.2 in v3.00 C Compiler manual). The new compiler is overly aggressive in its optimizations. If y() is modified to call x() then code is generated for x() unless the optimizer is also invoked (by using -x2). ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00014430 ------------------------------------------------------------------------------- Summary : calloc doesn't check arguments to make sure the requested size is reasonable Affected Component : Runtime Support Libraries (RTS) Description: The function calloc() is required to return a pointer to memory representing "nelem" copies of "size" bytes, or NULL if the request cannot be satisfied. However, for some values of "nelem" and "size" (specifically when the result of nelem*size wraps around), calloc can return a pointer to an object that is not large enough, rather than NULL. For example, on a 32-bit target, if the user calls calloc(0x00010001, 0x00010001), even though each argument by itself is reasonable, the request cannot be satisfied because the product is 0x000100020001, which exceeds size_t. (Note that we cannot check for overflow by checking if the product is less than either argument, which is commonly done for unsigned addition.) Arguably, we can try to claim that it is undefined behavior to make a call to calloc where the product would exceed size_t, but there doesn't seem to be anything in the standard which says so. The problem is worse on 16-bit targets, where calloc(0x0101, 0x0101) is enough to overflow size_t. It may not be obvious to the user that this overflows. Another concern is that it is hard to figure out whether a multiplication will overflow without having a double-width multiply available. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00018691 ------------------------------------------------------------------------------- Summary : Linker gives misleading warning when dot expressions used in SECTION directive for .stack section Affected Component : Linker Description: Linker gives the warning: warning: creating ".stack" section with default size of 0x800; use the -stack option to change the default size even when the application does not link in boot code from RTS lib. A linker command file is used that contains a specialized SECTION directive for the ".stack" section. Because of a series of ". += " 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 SDSCM00036770 ------------------------------------------------------------------------------- Summary : LDREXD and STREXD instructions erroneously generate errors on Cortex A8 and R4 Affected Component : Assembler Description: LDREXD and STREXD are valid instructions on Cortex R4 and A8 architectures but the assembler generates errors. The first error states that [Rn] must be a register indirect and the second complains of unexpected trailing operands. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00036773 ------------------------------------------------------------------------------- Summary : LDM/STM -DA/FA/IB/ED viariant instructions erroneously accepted by assembler for Cortex-M3 Affected Component : Assembler Description: LDM and STM instructions ending with DA, FA, IB and ED are not available in the Thumb instruction set, but the assembler accepts these for Cortex-M3 and converts them to LDM and STM instructions ending with IA.W. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00036874 ------------------------------------------------------------------------------- Summary : Section relative ELF symbol values in partially linking object files should hold the section offset for the symbol Affected Component : ELF Linker Description: The symbol value in an ELF relocatable file should be the offset from the beginning of the section. Typically the sections all start at address 0, so the value corresponds to its address in the file. In a partially linking object file, the sections will start at different addresses. The symbol values contain the absolute address instead of the offset. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037008 ------------------------------------------------------------------------------- Summary : Linker outputting wrong build attribute name for EABI TAG_VFP_arch on ARM targets Affected Component : ELF Linker Description: For TMS470, linker outputs EABI build attribute TAG_VFP_arch name as "Producer Minor Version + 1" instead of the correct name for the specific tag value. The TI build attribute TAG_VFP_arch name is printed correctly. The names are entered correctly for the EABI VFP_arch tag values but are not being accessed. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037086 ------------------------------------------------------------------------------- Summary : ARM assembler allows incorrect VFP registers for some instructions on D16 VFP architectures Affected Component : Assembler Description: ARM assembler allows the use of VFP registers D16-D31 on D16 VFP targets for the following VFP instructions: single and multiple loads and stores, pop, push, and register transfers between VFP and core registers. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037227 ------------------------------------------------------------------------------- Summary : ARM disassembler error for VMRS instruction Affected Component : Disassembler (dis) Description: The ARM disassembler errorneously disassembles "VMRS APSR_[bits], FPSCR" as "VMSR PC, FPSCR". The instruction is formatted as "FMSTAT" in the code generator in vfp.md (vfp_transfer_status_to_cpsr). ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037308 ------------------------------------------------------------------------------- Summary : Assembler does not encode the proper offset for a VLDR immediate instruction in thumb 2 mode Affected Component : Assembler Description: In thumb 2 mode, the value of the PC register at a given instruction is PC+4 (in ARM it is PC+8). When encoding the VLDR instruction the assembler always encodes the instruction as if the PC is PC+8. This will cause the VLDR instruction to never work correctly in thumb 2 mode. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00038278 ------------------------------------------------------------------------------- Summary : ARM floating point conversion routines do not support NaN Affected Component : Runtime Support Libraries (RTS) Description: The ARM assembly routines that handle converting floating point types do not handle NaN correctly. In these routines NaN is considered to be infinity. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00039220 ------------------------------------------------------------------------------- Summary : Assembler does not accept the SP operand of the SRSDB instruction Affected Component : Assembler Description: The assembler accepts SRSDB #, but the reference manual specifies that the instruction should have an SP! operand. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00039626 ------------------------------------------------------------------------------- Summary : ARM assembler does not issue a warning for PC-relative loads when --embedded_constants=off Affected Component : Assembler Description: When the --embedded_constants=of option is used, the assembler is supposed to issue an error message if it detects any PC-relative loads. It does this for LDR instructions that are 32-bits long, but not for the 16-bit versions. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00039636 ------------------------------------------------------------------------------- Summary : When creating a partial linked ELF object file, the linker uses virtual addresses instead of relative addresses. Affected Component : Linker Description: In ELF, relocatable object files should always using section relative values for relocation offsets and symbols values. When creating a partially linked object file the linker uses virtual addresses for these values. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00040522 ------------------------------------------------------------------------------- Summary : _ssatl intrinsic allows 3rd argument to be 0 resulting in an assembler error. Affected Component : Parser Description: The SSAT instruction does not accept a 0 for the immediate argument. We should ensure in the parser that 0 is not allowed. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00040523 ------------------------------------------------------------------------------- Summary : The _ssat16 intrinsic allows literals in the range of 0-31, but the SSAT16 instruction only accepts values from 1-16 Affected Component : Parser Description: The parser should catch this so the assembler doesn't generate an error. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00040934 ------------------------------------------------------------------------------- Summary : Structure is not initialized correctly when using -o2 or -o3 optimization Affected Component : Optimizer Description: There is a problem with the initialization of a structure using symbols generated in the linker command file. We use symbols generated in the linker cmd file using the dot operator. These symbols are used as an initial value for a class/struct with a constructor. In our case we want the difference of two addresses that the linker generates. When using optimization -o2 or -o3, the compiler generates .cinit entries instead of the constructor call. In those .init-entries it doesn't use the difference of the addresses; instead it uses the first symbol. When turning off optimization or using lower level of opt than -o2, the constructor calls are generated and the struct is initialized correctly. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00042418 ------------------------------------------------------------------------------- Summary : Internal error when compiling code with WEAK functions; linker crash Affected Component : C/C++ Compiler (cl) Description: /* Command line: cl470 --abi=eabi weak2.c -z -l c:\Programme\TexasInstruments\ccsv4\tools\compiler\tms470\lib\libc.a Resulting output: warning: output section ".data" refers to load symbol "weakFunc" and hence cannot be compressed; compression "rle" is ignored warning: output section ".data" refers to load symbol "weakFunc" and hence cannot be compressed; compression "rle" is ignored table.c:3601:internal fatal error #10225: (.cinit..data.load) This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. INTERNAL ERROR: lnk470 aborted This is a serious problem. Please contact Customer Support with this message and a copy of the input file and help us to continue to make the tools more robust. >> Compilation failure Toolchain: TMS470 4.6.4 or 4.6.6 on 32-bit WinXP SP3. */ #pragma WEAK(weakFunc); extern void weakFunc(); void (*ptr)() = weakFunc; int main() { if (ptr) ptr(); } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00042945 ------------------------------------------------------------------------------- Summary : -pdse=195 causes an error under EABI if any standard header file is included Affected Component : Runtime Support Libraries (RTS) Description: This is the same bug as CQ19871. The problem appears to be that _AEABI_PORTABILITY_CHECK is defined in terms of _AEABI_PORTABILITY_LEVEL != 0 where _AEABI_PORTABILITY_LEVEL is not defined. This same idiom is used in many header files. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00044035 ------------------------------------------------------------------------------- Summary : float library functions misbehave with -me --float_support=fpalib Affected Component : Runtime Support Libraries (RTS) Description: Fails with optmization, passes with --no_high_level_opt, but the optimizer seems to be doing the right thing. Something is swapping the words in the double. If the words for each float constant in the assembly code are reversed, the test case works. I don't know whether the compiler is creating the float constants with the wrong endianness or the library is handling it with the wrong endianness. See also the closely related SDSCM00044038 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00044038 ------------------------------------------------------------------------------- Summary : float library functions misbehave with --abi=eabi -mv5e -me --float_support=fpalib Affected Component : Runtime Support Libraries (RTS) Description: Looking at the assembly code test_number gets converted to a double like I would expect but the comparison fails. See also the closely related SDSCM00044035 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00046074 ------------------------------------------------------------------------------- Summary : Cortex-M0 library lacks uread4, etc. Affected Component : Runtime Support Libraries (RTS) Description: The ARM EABI requires the EABI library to provide four unaligned access helper functions: __aeabi_uread4 __aeabi_uread8 __aeabi_uwrite4 __aeabi_uwrite8 The other TI-provided EABI libraries provide these functions, but not the library for Cortex-M0. Workaround: If using the TI compiler, the TI compiler doesn't call any of these functions, so no workaround should be necessary. If using any other vendor's compiler and linking with the TI toolchain, link with the other vendor's toolchain. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00046102 ------------------------------------------------------------------------------- Summary : MISRA 12.8 and MISRA 10.5 false positives Affected Component : Parser Description: I was wondering if the compiler's MISRA checking is reporting false positives. I have the following code #define DEF_X (0x00000001UL) #define DEF_Y (4U) static void foo(void) { uint32 nReadData; nReadData = DEF_X << DEF_Y; } This gives me a MISRA error... #1397-D (MISRA-C:2004 10.5/R) If the bitwise operators ~ and << are applied to #an operand of underlying type unsigned char or unsigned short, the result #shall be immediately cast to the underlying type of the operand. But the underlying type is a "UL" or 32bit unsigned integer. If I try to fix the error using the code... nReadData = (uint32)DEF_X << DEF_Y; This gives me a MISRA error... #1407-D (MISRA-C:2004 12.8/R) The right-hand operand of a shift operator shall #lie between zero and one less than the width in bits of the underlying type #of the left-hand operand But the right hand operator has a value of 4 and the left hand operator is 32 bits. The only way I can solve the problem is by assigning the #define values to temporary variables and then doing the shift operation with these. With this in mind I think the misra checking is not handling the #define values correctly.. Am I correct in this assumption? ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00046352 ------------------------------------------------------------------------------- Summary : Disassembler does not emit certain instructions in UAL form by default Affected Component : Disassembler (dis) Description: See the test case for SDSCM00046351. For instructions combining the S flag and a condition code, UAL requires the S to appear before the condition code, but the disassembler puts it afterward, in the pre-UAL style: UAL syntax: LSLSEQ R2, R2, #2 LSLSNE R2, R2, #2 disassembler output: (7A8) MOVEQS R2, R2, LSL #2 MOVNES R2, R2, LSL #2 I've no idea whether UAL expects the LSL or MOV syntax. rv40fromelf -c ouputs the LSL form, so I assume that's the UAL form. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00047077 ------------------------------------------------------------------------------- Summary : Incorrectly reduced double constant to float when ultimate destination is short Affected Component : C/C++ Compiler (cl) Description: The expression ushort = 0.04f * 1000.0 gets a different value than ulong = 0.04f * 1000.0, even in strict mode. To understand what you're seeing, you need to be aware of these facts: The value 0.04 is not exactly representable in IEEE-754 binary floating- point format. The value used in the compiler is approximately 0.039999999105930328369140625 (exactly 0x1.47ae14p-5, in C99 hex format). 1000.0 is a double-precision float constant because you didn't use the 'f' suffix. 1000.0f is a single-precision float constant. When you perform arithmetic on floating-point types, rounding occurs When you perform arithmetic on mixed types, the compiler must promote them to a common type, usually the larger of the two. Now, what's going on is that you are multiplying the single-precision variable fTest by a double-precision value 1000.0. This requires the compiler to promote the value in fTest to a double, which means adding a bunch of zeros on the end. The compiler then rounds the double-precision result, which has a lot of zeros at the end, so it doesn't round up. Then the value gets truncated to an integer type for assignment to an integer. The parser assumes that (because the ultimate destination has only 16 bits) that it is safe to convert 1000.0 to 1000.0f; the problem is that this changes the result. This is safe if the ultimate destination is float, because double- >float conversion rounds, but double->integer truncates. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00047902 ------------------------------------------------------------------------------- Summary : Predefined macro __TI_FPv4SPD16_SUPPORT__ should be __TI_FPV4SPD16_SUPPORT__ Affected Component : Parser Description: The convention for predefined macros representing subtargets and features is to capitalize every letter. The predefined macro __TI_FPv4SPD16_SUPPORT__ should thus be __TI_FPV4SPD16_SUPPORT__. Recommend adding the latter, and keeping but deprecating the former ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00048267 ------------------------------------------------------------------------------- Summary : Warning generated when using __curpc intrinsic on Thumb 2 Affected Component : Code Generator Description: When using the __curpc intrinsic in Thumb 2 mode, the compiler generates code for which the assembler gives a warning. This should not affect the execution of the __curpc instruction, but could indicate incorrect execution of surrounding instructions. "file.asm", WARNING! at line 54: [W0004] Invalid instruction modifier(s) ignored MOVR A1, PC; MOVE REG-TO-REG ; [DPU_4_PIPE0] |2| ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049278 ------------------------------------------------------------------------------- Summary : Array that is correctly initialized erroneously gets a MISRA diagnostic about size not being specified Affected Component : Parser 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 SDSCM00049280 ------------------------------------------------------------------------------- Summary : Ill advised enum scalar usage gets MISRA diagnostic, but similar usage of enum array does not Affected Component : Parser 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 SDSCM00049284 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 10.1 Affected Component : Parser Description: Compiler misreports MISRA warning 10.1/R for the following code. typedef enum _MyEnum { One, Two } MyEnum; MyEnum MyVariable; int foo(void) { int result = 1; if (One == MyVariable) // fails here with MISRA-C:2004 10.1/R { result = 2; } return result; } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049911 ------------------------------------------------------------------------------- Summary : __aeabi_dcmpun returns 1 for Inf and -Inf Affected Component : Runtime Support Libraries (RTS) Description: ARM EABI function __aeabi_dcmpun is a binary function which returns 1 if either operand is NaN, and 0 otherwise. However, when either operand is +-Inf, it returns 1. __aeabi_dcmpun does not have this bug. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050131 ------------------------------------------------------------------------------- Summary : Local struct with non-constant initializer treated as static scope variable Affected Component : Parser Description: We've discovered a problem where the C++ compiler places a local structure variable not on the stack but in the data segment, as if it was a static structure. The problem is especially insidious because the issue will only have an impact on re-entrance. The problem seems to occur only for C++ files, and only if the structure initializer list contains a variable. Constant initializer lists do not trigger the issue. The structure in the first function will be allocated on the stack, but the structure in the second will be compiled as if it was declared static. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050499 ------------------------------------------------------------------------------- Summary : The .label assembler directive should not be accepted when assembling for ELF. Affected Component : Assembler Description: The .label directive creates a symbol that will have the value of the load address of a section. This cannot be done in ELF so the directive should issue an error. It's usefulness has been subsumed by other mechanisms (symbols defined in the linker command file and copy tables). ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050861 ------------------------------------------------------------------------------- Summary : Should accept 2-operand add in ARM mode Affected Component : Assembler Description: TI's assembler does not accept the 2-operand syntax for specifying the 3- operand ARM ADD instruction. Although the UAL doesn't seem to require the tool to allow this syntax, RVCT accepts this form, so we should, too. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051065 ------------------------------------------------------------------------------- Summary : Should accept 2-operand SUB SP in Thumb1/UAL mode Affected Component : Assembler Description: In thumb1/UAL mode, the assembler mistakenly emits an error when given the instruction "SUB SP, SP, #508" This syntax is specified directly in the ARM, so it should be supported. In thumb2 mode, the assembler mistakenly turns this into a 32-bit SUB.W SP, SP, #508. It should instead be a 16-bit instruction. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051069 ------------------------------------------------------------------------------- Summary : Should allow "ADD R0, R1, #0xfff" for v6m0 Affected Component : Assembler Description: The non-status setting two-register ADD immediate was actually added for T2, so it can be used on v6m0 as well. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051086 ------------------------------------------------------------------------------- Summary : Assembler accepts but mistranslates BLLT in v7 thumb mode Affected Component : Assembler Description: For v7 thumb 2 mode, the assembler should accept conditional instructions and automatically generate the appropriate IT instruction preceding it. (See SDSCM00051087) For v7 thumb mode, the assembler should accept the BLLT instruction, which is BL conditioned with LT, and turn it into "IT LT" followed by "BL LT." However, it accepts the instruction and turns it into "BL", which is wrong. While SDSCM00051087 is unsatisfied, the assembler should emit an error for "BLLT." After SDSCM00051087 is satisfied, the assembler should accept it and turn it into "IT LT" followed by "BL LT". ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051111 ------------------------------------------------------------------------------- Summary : Missing AEABI_COMPATIBILITY_MODE link-time constants Affected Component : Runtime Support Libraries (RTS) Description: The RTS is missing the following link-time constants required in AEABI_COMPATIBILITY_MODE mode: __aeabi_HUGE_VAL __aeabi_HUGE_VALF __aeabi_HUGE_VALL __aeabi_INFINITY __aeabi_NAN __aeabi_LC_ALL Can we even represent HUGE_VAL, as it is a 64-bit value and our linker only has 32-bit constants? ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051113 ------------------------------------------------------------------------------- Summary : Missing __aeabi_read_tp Affected Component : Runtime Support Libraries (RTS) Description: Function __aeabi_read_tp is required for ARM EABI compatibility, but we don't provide it. TI does not support thread-local-storage for ARM, but C6x has it, so it wouldn't be that difficult to add. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051114 ------------------------------------------------------------------------------- Summary : Missing half-precision float conversion functions Affected Component : Runtime Support Libraries (RTS) Description: The half-precision float conversion functions are required for ARM EABI compatibility, but we don't provide them. TI does not support half-precision float, but these functions are still required for interlinking. These functions are: __aeabi_d2h __aeabi_d2h_alt __aeabi_f2h __aeabi_f2h_alt __aeabi_h2f __aeabi_h2f_alt ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051165 ------------------------------------------------------------------------------- Summary : Should accept "LDRD R8,[R1]" in Thumb-2 mode Affected Component : Assembler Description: The assembler should accept "LDRD R8,[R1]" and translate it as if it were the canonical form "LDRD R8,R9,[R1]". It does do this in ARM mode, but fails to do so in Thumb-2 mode. RVDS accepts it in both modes. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051353 ------------------------------------------------------------------------------- Summary : MISRA does not recognize #pragma as preprocessing directive for 19.1 Affected Component : Parser Description: MISRA does not recognize #pragma as preprocessing directive for 19.1. 19.1 says that "#include statements in a file should only be preceded by other preprocessor directives or comments", but #pragma is... ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051367 ------------------------------------------------------------------------------- Summary : Disable diagnostic 1558 (--float_operations_allowed diagnostic) in standard header files Affected Component : Runtime Support Libraries (RTS) Description: The --float_operations_allowed option is used to identify floating point operations and issue an error if the user doesn't want them in the program. A program that includes math.h will generate diagnostics if either none or 32 is used as an argument. The emitting of the diagnostics is probably OK for none since users really shouldn't include math.h if no floating point is to be done, but it is a problem for 32-bit operations. If a user wants to only use 32-bit floating point, it is reasonable for them to include math.h. We should suppress the diagnostics from the standard header files. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051484 ------------------------------------------------------------------------------- Summary : Compiler does not respect partial overrides in C99 designated initializers Affected Component : Parser Description: Compiler does not respect partial overrides in C99 designated initializers Caught by ACE C99/6/7/8/t7.c See function lower_aggregate_designated_initializers in lower_init.c Both GCC-4.9.2 and EDG 4.4.1 behave this way. This appears to be a standard interpretation issue. The standard says "The initialization shall occur in initializer list order, each initializer provided for a particular subobject overriding any previously listed initializer for the same subobject." EDG apparently interprets this in the case of { .m = x, .m.a = 1, .m.b = 2 } with .m.a overriding the entire initialization .m=x; but in that case why doesn't .m.b override .m.a? ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051485 ------------------------------------------------------------------------------- Summary : Incorrect reordering of complicated float expression Affected Component : Optimizer Description: When the optimizer is used, the result is incorrect, even when -- fp_mode=strict is used. The problem is that the optimizer is incorrectly rearranging the complicated float expression in the increment part of the for loop ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051556 ------------------------------------------------------------------------------- Summary : formal parameter of strtod should be const char ** Affected Component : Runtime Support Libraries (RTS) Description: C99 expects the formal parameters of strtod to be const char **, but we don't define it that way. Same with strtold. Furthermore, strtof doesn't exist (see SDSCM00052146) ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051660 ------------------------------------------------------------------------------- Summary : When the imaginary part of z is INFINITY, cprojf(z) is NOT equivalent to INFINITY + I * copysign(0.0, cimagf(z)) Affected Component : C/C++ Compiler (cl) Description: When the imaginary part of z is INFINITY, cprojf(z) is equivalent to INFINITY + I * copysign(0.0, cimagf(z)) ------------------------------------------------------------------------------- KNOWN ISSUE CODEGEN-25 ------------------------------------------------------------------------------- Summary : Linker fails to allocate section which exactly fits the chosen memory range Affected Component : Unknown Description: Extract the attached zip file into an empty directory. % armcl -@options.txt "CC1310DK_7XD.cmd", line 82: error #10099-D: program will not fit into available memory. placement with alignment fails for section ".version" size 0x14 . Available memory ranges: VERSION size: 0x14 unused: 0x14 max hole: 0x14 error #10010: errors encountered during linking; "hello_CC1310DK_7XD_TI_CC1310F128.out" not built >> Compilation failure The section .version comes from the file hello.obj. It is exactly 0x14 (20) bytes long. And it is not aligned. So it should allocate into the VERSION memory range. ------------------------------------------------------------------------------- KNOWN ISSUE CODEGEN-1299 ------------------------------------------------------------------------------- Summary : Document the switch --no_stm Affected Component : Documentation Description: Document the switch --no_stm. Include any known limitations, aspects of the related silicon bug (DEVICE#B064) that --no_stm does not work around. Note in particular whether the stack can be allocated to external memory. It appears it cannot, because several hand-coded assembly routines in the RTS use STM instructions to preserve registers on the stack. ------------------------------------------------------------------------------- KNOWN ISSUE CODEGEN-1312 ------------------------------------------------------------------------------- Summary : RTS header errno.h no longer defines POSIX macros like EFAULT Affected Component : Runtime Support Libraries (RTS) Description: The errno.h of ARM compiler version 5.2.x defines macros like EFAULT and EFBIG. That macros come from the POSIX standard. They are not strictly required by the standard, but because they are there developers inside and outside of TI now expect them. The errno.h of ARM compiler version 15.12.x.LTS does not define these macros. ------------------------------------------------------------------------------- KNOWN ISSUE CODEGEN-1330 ------------------------------------------------------------------------------- Summary : Implementation of _disable_interrupts is wrong Affected Component : C/C++ Compiler (cl) Description: A forum customer complains that the _disable_interrupts intrinsic, for Cortex-M4, maps to CPSID f, but it should map to CPSID i. Please check whether this is correct, and make any necessary changes. Make the same check for _enable_interrupts(). ------------------------------------------------------------------------------- KNOWN ISSUE CODEGEN-1438 ------------------------------------------------------------------------------- Summary : Using isnan (and friends) in a custom object library built with 5.2.x compiler means that library cannot be linked with the 15.12.x.LTS or higher compiler Affected Component : Runtime Support Libraries (RTS) Description: % type try1.c #include int fxn(float fval) { if (isnan(fval)) return 10; return 20; } % armcl --abi=eabi try1.c % armnm try1.obj | find "class" 00000000 U _FDclass Pretend that try1.obj is not a single object file, but a library that is shipped to many customers. The symbol _FDclass is defined in the RTS library. But only the libraries that use the code we licensed from Dinkumware. This is version 5.2.x and earlier. Pretend this try1.obj library is linked with a 15.12.x.LTS compiler. The symbol _FDclass is not defined. The link fails with something like ... undefined first referenced symbol in file --------- ---------------- _FDclass C:/ti/TivaWare_C_Series-2.1.2.111/examples/boards/ ek-tm4c1294xl-boostxl-senshub/senshub_iot/ccs/../../../../../ sensorlib/ccs/Debug/sensorlib.lib error #10234-D: unresolved symbols remain error #10010: errors encountered during linking; "senshub_iot.out" not built >> Compilation failure ------------------------------------------------------------------------------- KNOWN ISSUE CODEGEN-1484 ------------------------------------------------------------------------------- Summary : The armhex command does not handle spaces in the name of the output binary Affected Component : Hex Converter (hex) Description: The armhex command does not seem to be able to handle spaces in the name of the output binary... even if it is wrapped in quotes. It will simply name the file with a truncated name (example: "My Dot Out File Has Spaces.out" becomes "My"). Strange, since it can handle in the name of the input *.out file just fine, Workaround: Rename it. ------------------------------------------------------------------------------- KNOWN ISSUE CODEGEN-1495 ------------------------------------------------------------------------------- Summary : Compiler and assembler disagree on format for IT instruction Affected Component : C/C++ Compiler (cl) Description: The attached test case produces the following diagnostic ... C:\some\dir>armcl -@options.txt try1.c "C:\Users\a0321429\AppData\Local\Temp\0998410", WARNING! at line 82: [W0004] Missing condition code inside of IT block CPSIE i ; [DPU_4_PIPE0] |13| No Assembly Errors, 1 Assembly Warning ------------------------------------------------------------------------------- KNOWN ISSUE CODEGEN-1498 ------------------------------------------------------------------------------- Summary : Automatic library build fails when an exact library name is used Affected Component : ELF LinkerDescription: Description: The file hello.c contains a typical hello world program. The first command builds the program in normal fashion, without specifying any RTS library name. It works fine. The second command deletes the library. The third differs from the first only that it exactly names the RTS library to use. This is the same as the library built in the first command. Nonetheless, the library build fails. C:\some\dir>armcl -mv7A8 --code_state=32 --float_support=VFPv3 -me --neon hello.c -z -o hello.out -m hello.map warning: automatic library build: using library "C:\ti\ccsv6\tools\compiler\ti-cgt-arm_15.12.1.LTS\lib\rtsv7A8_A_le_n_v3_eabi.lib" for the first time, so it must be built. This may take a few minutes. C:\some\dir>del \ti\ccsv6\tools\compiler\ti-cgt-arm_15.12.1.LTS\lib\rtsv7A8_A_le_n_v3_eabi.lib C:\some\dir>armcl -mv7A8 --code_state=32 --float_support=VFPv3 -me --neon hello.c -z -o hello.out -m hello.map -l rtsv7A8_A_le_n_v3_eabi.lib error: cannot find file "rtsv7A8_A_le_n_v3_eabi.lib" warning: automatic library build: using library "C:\ti\ccsv6\tools\compiler\ti-cgt-arm_15.12.1.LTS\lib\rtsv7A8_A_le_n_v3_eabi.lib" for the first time, so it must be built. This may take a few minutes. error: errors encountered during linking; "hello.out" not built >> Compilation failure Workaround: Do not specify the name of the library. ------------------------------------------------------------------------------- KNOWN ISSUE CODEGEN-1499 ------------------------------------------------------------------------------- Summary : #pragma LOCATION and palign do not work together Affected Component : ELF LinkerDescription: Description: The customer does this in his C code ... #pragma LOCATION(device_fw_info_ptr , 0x00018000) const volatile device_fw_info_t* const device_fw_info_ptr = &device_fw_info; ... and this in the linker command file ... .TI.bound:device_fw_info_ptr > FLASH0 palign(8), fill = 0xffffffff The palign is ignored. This section should be 8 bytes in length, the last four bytes filled with 0xff. But it is only four bytes long. Workaround: One workaround is to use specific placement in the linker command file. In the C code, replace the #pragma LOCATION with a #pragma DATA_SECTION ... #pragma DATA_SECTION(device_fw_info_ptr, "for_device"); And in the linker command file, replace the whole .TI.bound line with this ... for_device > 0x00018000, palign(8), fill = 0xffffffff ------------------------------------------------------------------------------- KNOWN ISSUE CODEGEN-1500 ------------------------------------------------------------------------------- Summary : Compiler and documentation disagree on spelling of #pragma pack. Compiler: pack Manual: PACK Affected Component : C/C++ Compiler (cl) Description: The compiler manual documents #pragma PACK. But the compiler itself only works with #pragma pack. One must be changed to match the other. ------------------------------------------------------------------------------- KNOWN ISSUE CODEGEN-1523 ------------------------------------------------------------------------------- Summary : Compiler incorrectly issues error message when it sees a designated initializer used for a union nested inside a structure Affected Component : C/C++ Compiler (cl), Parser Description: %> armcl try1.c "try1.c", line 43: error: union "" has no field "s1_f2" 1 error detected in the compilation of "try1.c". >> Compilation failure This builds clean with a recent version of GCC.Workaround: "