[Bug c/115770] New: Undefined arm instruction (udf #255) is generated when optimizer is on O2

[manuel.koeppen at gmx dot de]

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?