https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115770
Bug ID: 115770
Summary: Undefined arm instruction (udf #255) is generated when
optimizer is on O2
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: manuel.koeppen at gmx dot de
Target Milestone: ---
If you compile this
static inline void set_msp(unsigned int stackpointer)
{
__asm volatile ("msr msp, %0" : : "r" (stackpointer) : );
}
int main() {
set_msp(*((const unsigned int *)0));
return 0;
}
with for exmaple
arm-none-eabi-gcc -save-temps=cwd -O2 -mcpu=cortex-m4 -Wall -c -o main.o
main.c
an undefined instruction is produced when set_msp is "called" (in this case
inlined but it doesn't matter).
To explain the code: At address 0 you have the vector table and the first long
is the initial stack pointer so I wanted to grab it from there and set msp to
it. This code is simplified to demonstrate the problem.
If you use -O1, the generated code is correct!
movs r0, #0
ldr r3, [r0]
msr msp, r3
If you use -O2, the generated code is garbage (from .s file):
movs r3, #0
ldr r3, [r3]
.inst 0xdeff
The undefined instruction will cause an exception.
As I said it is not the inlining.
If you change the set_msp to
__attribute__((noinline)) static void set_msp(unsigned int stackpointer)
the code with -O1 will be correct:
movs r4, #0
ldr r0, [r4]
bl set_msp
and with -O2 the udf #255 again:
movs r3, #0
ldr r3, [r3]
.inst 0xdeff
(same as above). BTW objdump will show it as
main():
0: 2300 movs r3, #0
2: 681b ldr r3, [r3, #0]
4: deff udf #255 @ 0xff
As I did not want to turn off optimizations, only workaround was to put the
correct code in an asm statement directly.
I tried with compilers gcc 9.2.0 up to 14.1.0, linux and windows binaries, all
I tested showed the same behaviour.
P.S.: I selected the "c" component, although it could be in the
rtl-optimization, perhaps?
