cortex-m3 codegeneration error

Bug #1826318 reported by Duane Ellis
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Arm Embedded Toolchain
New
Undecided
Unassigned

Bug Description

This bug occurs with:

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

I am running this on a WINDOWS 10 host.

I have not yet tried newer compiler versions - for internal reasons I need to stick with this version.
i have a work around I am not blocked.

Attached are 4 files:

a) cut_down.c - tiny C file that demostrates the issue.

  This is the result of using "-E" (preprocessor)
  Then removing all of the extra stuff
  Keeping *ONLY* what is required.

b) cut_down.bat - windows batch file to execute gcc.

c) cut_down.txt - an "@" response file for GCC used by the BATCH file.

d) cut_down.s - the generated assembler output.

In the ASM output - you will see:

.LVL0:
 movs r2, #100
 add r1, r4, #172
 add r0, r4, #272
 bl memcpy
       /* THIS call to MEMCPY IS CORRECT */
.LVL1:
 add r0, r4, #272
.LVL2:
.L4:
 add r2, sp, #4
 mov r1, r6
 bl strtok_r
      /* this call to STRTOK_R is correct */
.LVL3:
 ldrsb r3, [r0]
 cmp r3, #35

       /* this is the "if( *cp2 == '#' )" is correct. */

       /* R5 = the CP1 value */
 mov r5, r0
.LVL4:
        /* I think this is the BRANCH for the '#' compare above.
 beq .L1

       /* what is missing is the NULL test here */

.LVL5:
       /* this is the test for "if ( CLI_common.argc >= 0x20 )"
 ldr r3, [r4, #372]
 cmp r3, #19
 ble .L3
 movs r1, #20
 mov r0, r7
.LVL6:
 bl CLI_error
.LVL7:
.L3:

Tags: ice
Revision history for this message
Duane Ellis (duanesd) wrote :
Revision history for this message
Andre Vieira (andre-simoesdiasvieira) wrote :

Hi Duane,

The removal of the 'cp2 == null' after you have dereferenced cp2 is not a bug, but a feature. The compiler uses the fact that dereferencing null is Undefined Behaviour to assume that cp2 can not be null. Since if it had been null, the program may choose to behave in any way it chooses, so not checking for null is a valid behavior.

As for the assignment to 0, I'm pretty sure it is still in the generated code, just before the jump back to .L4 there is a 'movs r0, #0' which is just that.

So I do not think any of this code-gen is wrong. I suggest you check for null first and only then dereference.

tags: added: ice
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.