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.

C2000 Optimization Option brings some problem

It seems that there's a problem in the compiler when using optimization option(-O0 through -O3, I didn't test -O4 option). Refer to the following two sample codes. Note that the only difference in each code is just one line which marked as bold red in the Code 2.

Even though wTuneCnt and cntTest has the same value, iTest101 and iTest102 has a different value.

The tested compiler versions are 4.1.3, 5.2.12, 6.4.9.

(Code 1)

case STEP5: 
pTraceData[(wTuneCnt - 1) * 2] = iLAMdssVoltEst;
pTraceData[(wTuneCnt - 1) * 2 + 1] = iIdseSamp ;
iTest100 = iLAMdssVoltEst;
iTest101 = pTraceData[(wTuneCnt - 1) * 2];
iTest102 = pTraceData[cntTest*2 - 2];
iTest103 = pTraceData[(cntTest - 1) * 2];
wTest100 = wTuneCnt;
wTest101 = cntTest;
// wTest103 = cntTest*2 - 2;

Result

iTest101 = -10748
iTest102 = 0

(Code 2)

case STEP5: 
pTraceData[(wTuneCnt - 1) * 2] = iLAMdssVoltEst;
pTraceData[(wTuneCnt - 1) * 2 + 1] = iIdseSamp ;
iTest100 = iLAMdssVoltEst;
iTest101 = pTraceData[(wTuneCnt - 1) * 2];
iTest102 = pTraceData[cntTest*2 - 2];
iTest103 = pTraceData[(cntTest - 1) * 2];
wTest100 = wTuneCnt;
wTest101 = cntTest;
wTest103 = cntTest*2 - 2;

iTest101 = -10748
iTest102 = -10748

The asm file for each code is shown below. The left is code 1, the right is code 2.

I can't figure out what is the problem?

  • It is not unusual that the assembly output is different in those two cases.  I don't see how those two assembly sequences can compute a different result.

    But to do better analysis, we need a test case which allows us to generate the same assembly.  Please send in the preprocessed form of the source file which contains this code.  Indicate, in the preprocessed file, the location of the problem lines.  And show all the build options exactly as the compiler sees them.

    Thanks and regards,

    -George

  • The line by line analysis of the left assembly code reveals that it has a problem.

    iTest102 = pTraceData[cntTest*2 - 2];

    is translated into

            MOVW      DP,#_cntTest           ;(1)
            MOV       AL,@_cntTest            ; (2)
            ADD       AL,#32767                 ; (3) 
            MOVU      ACC,AL                    ;(4)
            LSL       ACC,1                          ; (5)
            ADDL      XAR4,ACC                 ;(6)
            MOVW      DP,#_iTest102          ;(7)
            MOV       AH,*+XAR4[0]            ; (8)
            MOV       @_iTest102,AH         ; (9)

    XAR4 is used as the address of pTraceData[cntTest*2 -2].

    Originally, XAR4 has the value of the address of pTraceData[0].

    By ADDL XAR4,ACC, XAR4 is supposed to have the address of pTraceData[cntTest*2 -2].

    But from the following analysis, it shows that XAR4 has a wrong value.

    At (4), ACC = cntTest + 32767

    At (5), ACC = (cntTest + 32767)<<1

    At (6), XAR4 = &pTraceData[0] + (cntTest + 32767)<<1

    But, (cntTest + 32767)<<1 is different from cntTest*2 - 2, which is the programmed in the C code.

    (cntTest+32767)<<1 = (cntTest+0x7fff)<<1 = (cntTest + 0x8000 – 1)*2 = cntTest*2 -2 + 0x10000 , which is incorrect,

    Is there a compiler which fixes this bug or any workaround?

  • What is the type of cntTest?
  • cntTest is unsigned int.
    And wTuneCnt is the same as cntTest.
  • Okay, I've created a test case which demonstrates a problem with 16-bit expressions as array index. I've submitted SDSCM00052881 to track that issue. I don't know for sure that this is exactly the problem you are having, but it seems likely. If you would like to submit a more complete test case, I can compare it with SDSCM00052881 to see if they are affected by the same bug. Please make sure you submit a compilable test case that has been pre-processed.
  • Compile options are

    Options=--preproc_only --preproc_with_compile Option -k -o3 --symdebug:coff -q -pr -pdv -pden -pds9 -pds190 -pds188 -fr".\Release" -i".\include" -i"C:\ti\c2000\cgtools_311\include" -d"LARGE_MODEL" -ml -v28

    Here's the preprocessed C code and the assembly code.

    int iArray10[10];
    unsigned int iIdx;
    int iValTest1;

    void test()
    {
    iValTest1 = iArray10[iIdx*2 -2];
    }

    ;***************************************************************
    ;* TMS320C2000 C/C++ Codegen                         PC v6.4.9 *
    ;* Date/Time created: Tue May 03 09:45:00 2016                 *
    ;***************************************************************
     .compiler_opts --float_support=softlib --hll_source=on --mem_model:code=flat --mem_model:data=large --object_format=coff --quiet --silicon_version=28 --symdebug:coff
    FP .set XAR2
     .file "test.c"
     .global _iIdx
    _iIdx: .usect ".ebss",1,1,0
     .sym _iIdx,_iIdx, 14, 2, 16
     .global _iValTest1
    _iValTest1: .usect ".ebss",1,1,0
     .sym _iValTest1,_iValTest1, 4, 2, 16
     .global _iArray10
    _iArray10: .usect ".ebss",10,1,0
     .sym _iArray10,_iArray10, 52, 2, 160,, 10
    ; D:\setup\TI\CCS\ti-cgt-c2000_6.4.9\bin\opt2000.exe C:\\Users\\ewlee\\AppData\\Local\\Temp\\044362 C:\\Users\\ewlee\\AppData\\Local\\Temp\\044364
    ; D:\setup\TI\CCS\ti-cgt-c2000_6.4.9\bin\ac2000.exe -@C:\\Users\\ewlee\\AppData\\Local\\Temp\\0443612
     .sect ".text"
     .clink
     .global _test
     .sym _test,_test, 32, 2, 0
     .func 13

    ;***************************************************************
    ;* FNAME: _test                         FR SIZE:   0           *
    ;*                                                             *
    ;* FUNCTION ENVIRONMENT                                        *
    ;*                                                             *
    ;* FUNCTION PROPERTIES                                         *
    ;*                            0 Parameter,  0 Auto,  0 SOE     *
    ;***************************************************************

    _test:
            MOVW      DP,#_iIdx             ; [CPU_U]
            CLRC      SXM                   ; [CPU_]
     .line 3
            MOV       AL,@_iIdx             ; [CPU_] |15|
            MOVL      XAR4,#_iArray10       ; [CPU_U] |15|
            ADD       AL,#32767             ; [CPU_] |15|
            MOV       ACC,AL << 1           ; [CPU_] |15|
            ADDL      XAR4,ACC              ; [CPU_] |15|
            MOV       AL,*+XAR4[0]          ; [CPU_] |15|
            MOV       @_iValTest1,AL        ; [CPU_] |15|
            LRETR     ; [CPU_]
            ; return occurs ; []
     .endfunc 16,000000000h,0

    ;***************************************************************
    ;* TYPE INFORMATION                                            *
    ;***************************************************************


     

  • Yes, that test case does suffer from the same bug. SDSCM00052881 is now in the high-priority queue. I don't have any further details at this point.