cortex-m3 codegeneration error
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-
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: | added: ice |
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.