Issue 119972
Summary Issues with udf when assembling for Cortex-M3
Labels new issue
Assignees
Reporter mateusz-banaszek
    When using clang to assemble for ARM Cortex-M3, I've come across 2 issues with the `udf` (Permanently Undefined) instruction. To illustrate:

```asm
.syntax unified

@ Issue 1
udf     #256

@ Issue 2
it eq
udfeq   #20
```

An attempt to assemble that using clang v19.1.5:

```
clang -nodefaultlibs -mcpu=cortex-m3 --target=armv7m-none-eabi ./example.s
```

results in 2 errors:

```
./example.s:4:9: error: operand must be an immediate in the range [0,255]
udf     #256
        ^
./example.s:8:1: error: instruction 'udf' is not predicable, but condition code specified
udfeq #20
^
```

However, I don't see a reason to that. *Arm v7-M Architecture Reference Manual* shows 2 instruction encodings: T2 accepts `imm16`, and both accept a condition:

> Encoding T1: UDF\<c> #\<imm8>
> Encoding T2: UDF\<c>.W #\<imm16>

Surprisingly, the [`udf-thumb-2-diagnostics.s`](https://github.com/llvm/llvm-project/blob/main/llvm/test/MC/ARM/udf-thumb-2-diagnostics.s) test verifies that clang does generate these errors. However, even after reviewing the [`27351f2`](https://github.com/llvm/llvm-project/commit/27351f2022c56b830f91d7f526775693fd9043e9) commit which implemented `udf`, I still don't see a reason to that. I expect that the snippet is assembled to:

```
f7f0 a100   udf.w #256
bf08   it eq
de14   udfeq #20
```

So I expect that for Issue 1 clang chooses itself the wide encoding (as it does for, e.g., `adds r0, r1, #1024` vs. `adds r0, r1, #2`), whereas for Issue 2 clang assembles it as the instruction accepts the condition and it is predicable (*Arm v7-M Architecture Reference Manual*: *"`UNDEFINED` Indicates an instruction that generates an Undefined Instruction exception."*). GCC assembles it correctly: https://godbolt.org/z/Y8q7KbzKG.

Or is there something I don't understand?
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to