• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 640 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Compiler/RM46L852: Compiler/ARM-CGT: array[256] access out of bounds after explicit (uint8_t) cast of index, compiler bug?

Rainald Koch
Intellectual 610 points
Part Number: RM46L852


Tool/software: TI C/C++ Compiler

Hello,

we observe peculiar behavior with a code construct like this:

char arr[256];
[...]
uint32_t status32 = 0x01020304;
char out = *(arr + (uint8_t)(status32 >> 16)); // out of bounds access
char out = *(arr + (0xffu & (status32 >> 16))); // yields arr[2] as expected

Out of bounds access is inferred from the result being 0xff (arr does not contain 0xff).

This may be a compiler bug. Compiler is TI v15.12.5 TLS

  • 0
    TI__Guru**** 173310 points

    Does the compiler report an error when compiling this code or is it just that the result is unexpected? I will need to investigate further but the issue may stem from C rules for promotion and conversion rather than a compiler bug. I will get back when I have more information.

  • 0
    TI__Guru**** 251180 points

    Please show all the build options exactly as the compiler sees them.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 610 points

    Hi George,

    copied from the Properties > Compiler tab:

    -mv7R4 --code_state=32 --float_support=VFPv3D16 -me -O3 --opt_for_speed=5 --fp_mode=relaxed --include_path="C:/ti/ccsv6/tools/compiler/ti-cgt-arm_15.12.7.LTS/include" --include_path="D:/DRS05_3/DRS05/include" --include_path="D:/DRS05_3/DRS05/Radar/Includes" --include_path="D:/DRS05_3/DRS05/TPS_Driver/source" --include_path="D:/DRS05_3/DRS05/TPS_Driver/include" --display_error_number --diag_wrap=off --diag_warning=225 --enum_type=packed --abi=eabi

    Hi AartiG,

    no compiler errors.

    Thank you.

    Regards,

    Rainald

  • 0 in reply to Rainald Koch
    TI__Guru**** 173310 points

    Rainald,

    I am trying to reproduce this but have not been able to yet. Could you send us a simple cut-down CCS project (or at least a complete C source file) that can be run on a RM46 Launchpad and demonstrates this issue? I tried to construct something based on your code snippet but haven't had luck reproducing the 0xff result that you report. 

  • 0 in reply to AartiG
    TI__Guru**** 251180 points

    I am also unable to see any problems.  But I am only able to create a small test case based on what you show.  There is something in the surrounding context of the code which contributes to the problem.  For the source file which has the out of bounds access, please follow the directions in the article How to Submit a Compiler Test Case.  With this one change: After you create the preprocessed file, edit it and add // PROBLEM HERE to mark the line where the out of bounds access occurs.  I'll use the test case to build the file down to assembly code, then attempt to find the incorrect assembly code.  This often works, but not always.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 610 points

    Thank you for mentioning assembler, George. Since the problem has been solved by using the & operation, I suggested my colleague to compare the assembler output to spot the compiler bug.

    He found the original code to work fine, however, since he had updated the compiler. We changed our plan to compare the compiler versions.

    In order to locate the lines in the asm files, we moved the offensive code into a function:

    uint8_t TableRead(unsigned long int Status) {
 return *(StartStatTabelle + (uint8_t)(Status >> 16));
}

    Indeed, the assembler code looks different for versions 15.12.5 and 15.12.7:

    ;*****************************************************************************
;* FUNCTION NAME: TableRead                                                  *
;*                                                                           *
;*   Regs Modified     : A1,V9                                               *
;*   Regs Used         : A1,V9,LR                                            *
;*   Local Frame Size  : 0 Args + 0 Auto + 0 Save = 0 byte                   *
;*****************************************************************************
TableRead:
;* --------------------------------------------------------------------------*
;* A1    assigned to Status
$C$DW$162	.dwtag  DW_TAG_variable
	.dwattr $C$DW$162, DW_AT_name("Status")
	.dwattr $C$DW$162, DW_AT_TI_symbol_name("Status")
	.dwattr $C$DW$162, DW_AT_type(*$C$DW$T$167)
	.dwattr $C$DW$162, DW_AT_location[DW_OP_reg0]

	.dwcfi	cfa_offset, 0
	.dwpsn	file "../Radar/TxSIEM.c",line 228,column 2,is_stmt,isa 2
        MOVW      V9, ||$O1$$||+20      ; [DPU_4_PIPE0] |228| 
        MOVT      V9, ||$O1$$||+20      ; [DPU_4_PIPE0] |228| 
        LDR       V9, [V9, #0]          ; [DPU_4_PIPE0] |228| 
        LDRB      A1, [V9, +A1, LSR #16] ; [DPU_4_PIPE0] |228|

    Up to here, it is output of 15.12.5.LTS. The very last line is replaced by the following two lines from 15.12.7.LTS.

            UXTB      A1, A1, ROR #16       ; [DPU_4_PIPE0] |228| 
        LDRB      A1, [V9, +A1]         ; [DPU_4_PIPE0] |228|

    The remainder is identical.

    $C$DW$163	.dwtag  DW_TAG_TI_branch
	.dwattr $C$DW$163, DW_AT_low_pc(0x00)
	.dwattr $C$DW$163, DW_AT_TI_return

        BX        LR                    ; [DPU_4_PIPE1] 
        ; BRANCH OCCURS                  ; [] 
	.dwattr $C$DW$160, DW_AT_TI_end_file("../Radar/TxSIEM.c")
	.dwattr $C$DW$160, DW_AT_TI_end_line(0xe5)
	.dwattr $C$DW$160, DW_AT_TI_end_column(0x01)
	.dwendentry
	.dwendtag $C$DW$160

    EDIT:

    That major defect is/was CODEGEN-2320.