This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMS570LS3137: CCS10 ARM compiler TI v20.2.1.LTS

Part Number: TMS570LS3137

Tool/software: Code Composer Studio

We are planning to migrate CCS version from  6.0.1.00040  to  Version: 10.1.1.00004. Hence the compiler also we changing to ARM compiler TI v20.2.1.LTS. we wanted to understand is there any open issue (bugs) in this new compiler or is there any errata for this version? If yes then could you please share with us for our evaluation?

  • While ARM compiler version 20.2.1.LTS is installed as part of CCS version 10.1.1, further versions of that compiler have been released.  As detailed in the article Compiler Version Numbers and What They Mean, you ought to consider upgrading to the latest 20.2.x.LTS version, which is presently 20.2.4.LTS.

    Subash Sundaresan1 said:
    is there any open issue (bugs) in this new compiler or is there any errata for this version?

    This information is contained in the release notes for version 20.2.4.LTS.

    Thanks and regards,

    -George

  • Hi George,

    Thank you so much for your reply. The open issues are being analysed and it is halfway through. 

    Could you please elaborate following issues as we unable understand the description,

    1. "Should accept “LDRD R8,[R1]” in Thumb-2 mode" 

    2. "Assembler accepts but mistranslates BLLT in v7 thumb mode"

    3. armcl fails to flag an inconsistent use of alignas between a declaration and definition of an object

  • Subash,

    I was able to extract a little more data.  Is this what you need?  George is out for a week.

    Subash Sundaresan1 said:
    1. "Should accept “LDRD R8,[R1]” in Thumb-2 mode" 

    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.

    Subash Sundaresan1 said:
    2. "Assembler accepts but mistranslates BLLT in v7 thumb mode"

    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.

    Subash Sundaresan1 said:
    3. armcl fails to flag an inconsistent use of alignas between a declaration and definition of an object

    This one looks like a C++ specific issue:

    armcl fails to flag an inconsistent use of alignas between a declaration and definition of an object

    the armcl compiler correctly diagnoses an inconsistency in the usage of an alignas attribute, e.g.:

    struct alignas(char) S;
    struct S {};

    However, in the following case, armcl does not generate an error when it should:

    template <class> struct alignas(char) S;
    template <class> struct S {};

    Regards,

    John

  • Hi John,

    Thank you so much, your inputs are much appreciated.

    we are unable to produce following issues as mentioned in the compiler defect list, it appears to me working as expected. (CCS : Version: 10.1.1.00004 , ARM compiler version : 20.2.4.LTS.)

    CODEGEN-962 Should accept 2-operand SUB SP in Thumb1/UAL mode
    CODEGEN-927 Should accept 2-operand add in ARM mode
    CODEGEN-753 Warning generated when using __curpc intrinsic on Thumb 2
    CODEGEN-104 Linker gives misleading warning when dot expressions used in SECTION directive for .stack section.
    CODEGEN-56 Forward reference in .space generates an internal error

    Unable to understand the following issues, so could you please elaborate it,

    CODEGEN-3951 Spurious error on bypassing initialization of trivially constructible objects
    CODEGEN-1499 #pragma LOCATION and palign do not work together
    CODEGEN-1101 When the imaginary part of z is INFINITY, cprojf(z) is NOT equivalent to INFINITY + I * copysign(0.0, cimagf(z))
    CODEGEN-1059 Compiler does not respect partial overrides in C99 designated initializers
    CODEGEN-1026 Disable diagnostic 1558 (–float_operations_allowed diagnostic) in standard header files
    CODEGEN-975 Missing half-precision float conversion functions
    CODEGEN-974 Missing __aeabi_read_tp
    CODEGEN-972 Missing AEABI_COMPATIBILITY_MODE link-time constants
    CODEGEN-890 The .label assembler directive should not be accepted when assembling for ELF.
    CODEGEN-830 __aeabi_dcmpun returns 1 for Inf and -Inf
    CODEGEN-662 Double constant expression may be incorrectly truncated if assigned to a narrow integer type
    CODEGEN-316 The _ssat16 intrinsic allows literals in the range of 0-31, but the SSAT16 instruction only accepts values from 1-16
    CODEGEN-315 _ssatl intrinsic allows 3rd argument to be 0 resulting in an assembler error.
    CODEGEN-237 Linker outputting wrong build attribute name for EABI TAG_VFP_arch on ARM targets
    CODEGEN-235 Section relative ELF symbol values in partially linking object files should hold the section offset for the symbol.
    CODEGEN-63 DWARF does not correctly represent variables stored in register pairs
    CODEGEN-30 Compilers on PC will not work without TMP set

      

  • It would be much appreciated if you provide clarification on the above queries as earliest possible. 

  • Here is a partial reply.

    Subash Sundaresan1 said:
    CODEGEN-3951 Spurious error on bypassing initialization of trivially constructible objects

    For the C++ example code shown in the description, the compiler incorrectly issues diagnostics.  Instead, no diagnostics should be seen.

    Subash Sundaresan1 said:
    CODEGEN-1499 #pragma LOCATION and palign do not work together

    This issue was filed in response to this forum thread.

    Subash Sundaresan1 said:
    CODEGEN-1101 When the imaginary part of z is INFINITY, cprojf(z) is NOT equivalent to INFINITY + I * copysign(0.0, cimagf(z))

    The C99 standard adds many features to the compiler RTS library, including support for complex numbers.  One of these three functions related to complex numbers handles an unusual case not quite correctly.  If you don't use complex numbers, you can ignore this one.

    Subash Sundaresan1 said:
    CODEGEN-1059 Compiler does not respect partial overrides in C99 designated initializers

    Please see this forum post.

    Subash Sundaresan1 said:
    CODEGEN-1026 Disable diagnostic 1558 (–float_operations_allowed diagnostic) in standard header files

    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.

    Subash Sundaresan1 said:
    CODEGEN-975 Missing half-precision float conversion functions

    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

    Subash Sundaresan1 said:
    CODEGEN-974 Missing __aeabi_read_tp

    The function __aeabi_read_tp is required for ARM EABI compatibility, but we don't provide it. 

    Subash Sundaresan1 said:
    CODEGEN-972 Missing AEABI_COMPATIBILITY_MODE link-time constants

    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

    __aeabi_EDOM
    __aeabi_ERANGE
    __aeabi_EILSEQ

    Subash Sundaresan1 said:
    CODEGEN-890 The .label assembler directive should not be accepted when assembling for ELF.

    The .label assembler directive should no longer be accepted.  It is not valid in ELF object format, and there are several better methods for handling the load address of section. 

    Subash Sundaresan1 said:
    CODEGEN-830 __aeabi_dcmpun returns 1 for Inf and -Inf

    This is a function required by the ARM EABI.  It is related to unsigned comparison of double numbers.  It returns the wrong result in some circumstances.  If you don't use this function, then ignore it.

    Subash Sundaresan1 said:
    CODEGEN-662 Double constant expression may be incorrectly truncated if assigned to a narrow integer type

    Filed in response to this forum thread.

    Subash Sundaresan1 said:
    CODEGEN-316 The _ssat16 intrinsic allows literals in the range of 0-31, but the SSAT16 instruction only accepts values from 1-16

    The compiler does not check the 2nd argument to the intrinsic _ssat16 to make sure it is in the range 1-16.  If the user makes this mistake, the compiler does not issue a diagnostic, but the assembler does.  That's confusing.

    Subash Sundaresan1 said:
    CODEGEN-315 _ssatl intrinsic allows 3rd argument to be 0 resulting in an assembler error.

    The compiler does not check the 3rd argument to the intrinsics _ssata and _ssatl to be sure it is in the range 1-16.  If the user makes this mistake, the compiler does not issue a diagnostic, but the assembler does.  That's confusing.

    Subash Sundaresan1 said:
    CODEGEN-237 Linker outputting wrong build attribute name for EABI TAG_VFP_arch on ARM targets

    I am unable to reproduce this one.

    Subash Sundaresan1 said:
    CODEGEN-235 Section relative ELF symbol values in partially linking object files should hold the section offset for the symbol.

    This one is related to partial linking, a seldom used feature of the linker.  If you don't use partial linking, then ignore this one.

    Subash Sundaresan1 said:
    CODEGEN-63 DWARF does not correctly represent variables stored in register pairs

    When a variable is allocated to a register pair, the corresponding Dwarf debug information does not represent that correctly.  CCS works around this problem.

    Subash Sundaresan1 said:
    CODEGEN-30 Compilers on PC will not work without TMP set

    This problem does not occur with recent versions of the compiler, including TI ARM compiler version 20.2.x.LTS.

    Thanks and regards,

    -George

  • Here are replies on the issues I have not addressed.

    Subash Sundaresan1 said:
    CODEGEN-962 Should accept 2-operand SUB SP in Thumb1/UAL mode

    I cannot reproduce this one.

    Subash Sundaresan1 said:
    CODEGEN-927 Should accept 2-operand add in ARM mode

    The following is valid ARM assembly code ...

    ; Any line that is not a label or comment must begin with space or tab
            ADDS R1, R0
            ADD R1, R0

    But when building in ARM mode the assembler incorrectly issues error diagnostics ...

    % armcl -mv5e file.asm
    "file.asm", ERROR!   at line 2: [E0005] Missing operand(s)
                    ADDS R1, R0
    
    "file.asm", ERROR!   at line 3: [E0005] Missing operand(s)
                    ADD R1, R0

    Subash Sundaresan1 said:
    CODEGEN-753 Warning generated when using __curpc intrinsic on Thumb 2

    When looking into this one, I came across another problem with the __curpc intrinsic.  I filed EXT_EP-10216 to have it investigated.  You are welcome to follow it with that link.

    Subash Sundaresan1 said:
    CODEGEN-104 Linker gives misleading warning when dot expressions used in SECTION directive for .stack section.

    The linker incorrectly issues this warning ...

    warning: creating ".stack" section with default size of 0x800; use the -stack option to change the default size

    ... when the .stack section is created with lots of statements similar to ...

    symbol1 = .;
    . += 0x100;
    symbol2 = .;
    
    symbol3 = .;
    . += 0x100;
    symbol4 = .;
    
    /* and so on */
    

    A correct .stack section is created, and so the warning should not be issued.

    Subash Sundaresan1 said:
    CODEGEN-56 Forward reference in .space generates an internal error

    This example code ...

    ; Any line that is not a label or comment must begin with space or tab
    
            .space  0+a
    b
    a       .set    1

    ... causes an internal error when it is built ...

    % armcl file.asm
    
    INTERNAL ERROR: armasm experienced a segmentation fault
                      while processing section .text file file.asm line 3

    Change line 3 to .space a and the assembler correctly issues a diagnostic ...

    % armcl file.asm
    "file.asm", ERROR!   at line 3: [E0004] Absolute, well-defined integer value
                                            expected
                    .space  a

    Thanks and regards,

    -George

  • There are three issues for which previous replies are not clear.

    Subash Sundaresan1 said:
    CODEGEN-962 Should accept 2-operand SUB SP in Thumb1/UAL mode

    This is about two different, but closely related, problems.  The first is demonstrated with this example ...

    ; Any line that is not a label or comment must begin with space or tab
        SUB SP, SP, #508

    This is a valid instruction, even for Thumb1.  But when building for Thumb1 ...

    % armcl -mv5e --code_state=16 file.asm
    "file.asm", ERROR!   at line 2: [E0004] Register Rd cannot be a hi register
                SUB SP, SP, #508
    
    "file.asm", ERROR!   at line 2: [E0200] Offset out of range, must be 8 bit
                                            immediate
                SUB SP, SP, #508

    No error diagnostics should appear.

    The second problem ... When building the same instruction for Thumb2 ...

    % armcl -mv7m3 file.asm

    ... the assembler should encode a 16-bit SUB instruction.  Instead, it encodes a 32-bit SUB instruction.  That is a small waste of code space.

    Subash Sundaresan1 said:
    CODEGEN-237 Linker outputting wrong build attribute name for EABI TAG_VFP_arch on ARM targets

    This issue can no longer be reproduced.  It has been closed.

    Subash Sundaresan1 said:
    CODEGEN-30 Compilers on PC will not work without TMP set

    This is an issue only if you build on Windows and do not set the environment variables TMP or TEMP to a directory where temporary files can be created and deleted.  At this point, many Windows programs depend on these environment variables.  We are likely to change the compiler documentation to require that TMP or TEMP must be set.

    Thanks and regards,

    -George

  • Thank you so much for your response! 

    We couldn't find the description of following issues as well, it would be great if get answer for following issues as well,

    CODEGEN-5078 Simple syntax error causes assembler to fail with INTERNAL ERROR
    CODEGEN-4298 Internal error when passing a temporary array of objects
    CODEGEN-4258 deeply nested lambda functions hang the codegen
    CODEGEN-4124 Failure to defer access control checks
    CODEGEN-4015 Access of const static member through pointer is not a constant expression.
    CODEGEN-3999 Unimplemented core issue 1374: Conversion sequence ranks qualification before reference binding.
  • Subash Sundaresan1 said:
    CODEGEN-5078 Simple syntax error causes assembler to fail with INTERNAL ERROR

    Please see this forum thread.

    Subash Sundaresan1 said:
    CODEGEN-4298 Internal error when passing a temporary array of objects

    I am unable to reproduce this behavior.  I'll get back to you on it.

    Subash Sundaresan1 said:
    CODEGEN-4258 deeply nested lambda functions hang the codegen

    Here is an example of a nested lambda.

    int timestwoplusthree = [](int x) { return [](int y) { return y * 2; }(x) + 3; }(5);

    Some of the compiler tests intentionally push the limits far past what happens in typical practice, in order to check robustness.  One test contains a nested lambda 64 levels deep.  The compiler hangs when the build is attempted.  A hang means the compiler failed to complete the build within a few minutes.  Once that time is up, the automated testing system forces the build to end, and registers a failure.

    Subash Sundaresan1 said:
    CODEGEN-4124 Failure to defer access control checks

    The following C++ code is correct.

    class A {
      typedef int I; // private member
    friend I g(I);
      template<int> struct Q;
      template<int> friend struct R;
    protected:
      struct B { };
    };
    template<A::I> struct A::Q { };
    template<A::I> struct R { };

    However, the compiler issues error diagnostics ...

    % armcl file.cpp
    "file.cpp", line 9: error: type "A::I" (declared at line 2) is inaccessible
    "file.cpp", line 10: error: type "A::I" (declared at line 2) is inaccessible

    Subash Sundaresan1 said:
    CODEGEN-4015 Access of const static member through pointer is not a constant expression.

    Compile this example ...

    struct C {
        const static int m;
    };
    const int C::m = 4;
    
    C c;
    C *cp = &c;
    
    int main(void)
    {
        struct S02 {
            int x : cp->m; // error, not a constant expression
        };
    }

    using strict ANSI mode ...

    armcl --strict_ansi file.cpp
    "file.cpp", line 2: warning: storage class is not first
    "file.cpp", line 12: error: expression must have a constant value
    "file.cpp", line 12: note: the value of variable "cp" (declared at line 7) cannot be used as a constant

    The error diagnostic should not be issued.

    Subash Sundaresan1 said:
    CODEGEN-3999 Unimplemented core issue 1374: Conversion sequence ranks qualification before reference binding.

    The term core issue 1374 refers to this entry filed against the C++ standard.  That entry resulted in a change to the standard.  The TI compiler has not implemented this change.

    Thanks and regards,

    -George

  • Subash Sundaresan1 said:
    CODEGEN-4298 Internal error when passing a temporary array of objects

    For this C++ code ...

    #include <initializer_list>
    #include <stdio.h>
    
    struct S {
        int m;
        S(int i=1) : m(i) {}
        operator int() { return m; }
        int operator +(const S& r) { return m+r.m; }
    };
    
    int f00(S (&&r)[3])
    {
        return r[0] + r[1] + r[2];
    }
    
    int main(void)
    {
        int x, g;
    
        x = 100;
        g = f00({97, 2 });
    
        if (g != x)
            printf("Got %d instead of %d", g, x);
    
        return (2);
    }

    When built with debug enabled, the compiler fails with an internal error.

    % armcl -g file.cpp
    >> file.cpp, line 21: INTERNAL ERROR: Decomposition error

    Thanks and regards,

    -George

  • Thank you so much George for your inputs.

    CODEGEN-890 The .label assembler directive should not be accepted when assembling for ELF.

     - The .label assembler directive should no longer be accepted.  It is not valid in ELF object format, and there are several better methods for handling the load address of section. 

    However in assembler manual for load address examples they have used only ".label" directive. could suggest any equivalent directive for the same.

    CODEGEN-235 Section relative ELF symbol values in partially linking object files should hold the section offset for the symbol.

     In our project we have six executables to accomplish the application, in future we are planning to link all the binaries and make single image. does it require partial linking feature? If yes then what is the impact? 

     CODEGEN-5078 Simple syntax error causes assembler to fail with INTERNAL ERROR.

    I couldn't reproduce the above mentioned error, both arm and thumb-2 modes. I'm getting following error,

    "../source/dabort.asm", ERROR! at line 50: [E0004] The second operand must be an immediate value or symbol
    MOVW R1, 0x1234

  • Hi George,


    Thank you so much for your comprehensive reply, albeit I have few more questions:

    CODEGEN-5078 Simple syntax error causes assembler to fail with INTERNAL ERROR.

    I'm unable to reproduce this issue as I'm getting

    follwoing code:
    MOVW R1, 0x1234

    both arm and thumb-2 mode following error is annotated,

    Description Resource Path Location Type
    [E0004] The second operand must be an immediate value or symbol dabort.asm /test/source line 50 C/C++ Problem

    CODEGEN-890 The .label assembler directive should not be accepted when assembling for ELF.

    Per your reply "The .label assembler directive should no longer be accepted. It is not valid in ELF object format, and there are several better methods for handling the load address of section. "

    However in assembler reference manual for load address example they have used ".label" directive, could you please suggest appropriate directive for the load address operation.

    CODEGEN-235 Section relative ELF symbol values in partially linking object files should hold the section offset for the symbol.
    - You have replied "This one is related to partial linking, a seldom used feature of the linker. If you don't use partial linking, then ignore this one."

    Our project currently having multiple executable (binaries) in order accomplish the Application, however we are palling to link these binaries and make single image. In that scenario partial link have any impacts?

  • Subash Sundaresan1 said:
    CODEGEN-5078 Simple syntax error causes assembler to fail with INTERNAL ERROR

    This entry was filed in response to this forum thread.

    Subash Sundaresan1 said:
    CODEGEN-890 The .label assembler directive should not be accepted when assembling for ELF

    There is no direct replacement.  One alternative is to Load at One Address, Run from a Different Address.  Another alternative is the UNION directive.  When either technique is used, no .label directive is necessary.  

    Subash Sundaresan1 said:
    CODEGEN-235 Section relative ELF symbol values in partially linking object files should hold the section offset for the symbol.

    How do you plan to combine the multiple executables together?  If you don't use the linker, then this entry does not apply to you.

    Thanks and regards,

    -George

  • Thank you so much George,

    Could you please provide a real time example to elaborate the following issue,

    Subash Sundaresan1
    CODEGEN-63 DWARF does not correctly represent variables stored in register pairs

    When a variable is allocated to a register pair, the corresponding Dwarf debug information does not represent that correctly.  CCS works around this problem.

  • Start with this code example ...

    /* file.c */
    long long fxn(long long argument1, long long argument2)
    {
       return argument1 + argument2;
    }

    Build it.  Then use the object file display utility armofd with the -g option to collect the Dwarf debug information into the text file file_ofd.txt.

    % armcl -mv7r4 file.c
    % armofd -g -o file_ofd.txt file.obj

    Inspect file_ofd.txt. Search it for the names argument1 and argument2 to find ...

        000000c5   1       DW_TAG_formal_parameter (.text)
        000000c6              DW_AT_location       DW_OP_reg0
        000000c8              DW_AT_name           argument1
        000000d2              DW_AT_type           .debug_info(5) + 0x60
        000000d6              DW_AT_TI_symbol_name argument1
        000000e0   1       DW_TAG_formal_parameter (.text)
        000000e1              DW_AT_location       DW_OP_reg2
        000000e3              DW_AT_name           argument2
        000000ed              DW_AT_type           .debug_info(5) + 0x60
        000000f1              DW_AT_TI_symbol_name argument2
    

    To keep this post from being very long, I will not describe all of the details.  Ignore the DW_AT_TI_symbol_name.  The DW_AT_type entry means these arguments are of type long long.  The DW_AT_name entry is the name of the symbol from the C source.  The DW_AT_location field is the problem.  DW_OP_reg0 means the function argument is in A1.  It is actually in the register pair A1,A2.  It is the same for the other argument.  DW_OP_reg2 means it is in A3, but it is in the pair A3,A4.  The DW_AT_location parameter ought to be similar to ...

    { DW_OP_plus DW_OP_shl DW_OP_const1u 0x20 DW_OP_reg0 DW_OP_reg1 }

    That is prefix notation for (A1 << 32) + A2.

    CCS works around this problem.  When the type of the variable is larger than the register, it is presumes the next register contains the rest of the value.

    Thanks and regards,

    -George

  • Hi George,

    Thank you so much for your inputs, you inputs are very useful for my analysis!