Size optimization generates UDF instruction

[Marc Singer]

Greetings,

The attached sample produces machine code with a UDF instruction which appears to be an opcode that forces an undefined instruction exception. The current release, gcc-arm-none-eabi-6-2017-q2-update, and the previous release produce the same result. The source file includes the compile line used to generate the output.

Here is the code it generates:

00000000 <_Z9check_biti>:
   0: 2817 cmp r0, #23
   2: d802 bhi.n a <_Z9check_biti+0xa>
   4: 2300 movs r3, #0
   6: 681b ldr r3, [r3, #0]
   8: deff udf #255 ; 0xff
   a: 2000 movs r0, #0
   c: 4770 bx lr

What is also interesting is that the -thumb and -mcpu switches aren't important. Even with ARM instructions, we will see the UDF.

00000000 <_Z9check_biti>:
   0: e3500017 cmp r0, #23
   4: 8a000002 bhi 14 <_Z9check_biti+0x14>
   8: e3a03000 mov r3, #0
   c: e5933000 ldr r3, [r3]
  10: e7f000f0 udf #0
  14: e3a00000 mov r0, #0
  18: e12fff1e bx lr

If we change MAX to 32, the code compiles to something that works.

Cheers

[Tejas Belagod (belagod-tejas)]

This might be because of a bug in ARM backend for C++ zero-sized arrays. When you have MAX==24, WORD_WIDTH goes to 0 and rgb_ becomes a zero-sized array. Accessing zero-sized array data might be causing the ARM gcc backend to get confused.

I've raised https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81580 to track this.

[Tejas Belagod (belagod-tejas)]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81580 has resolved this as INVALID.