.option norvc is ignored with Zca

[Wren6991]

Repro

Input file: tmp.S, which contains a compressible instruction whose compression should be inhibited by .option norvc:

.option push
.option norvc
    addi a0, a0, -1
.option pop

When assembled for RV32IC:

$ /opt/riscv/corev/bin/riscv32-corev-elf-gcc -c -march=rv32ic tmp.S && /opt/riscv/corev/bin/riscv32-corev-elf-objdump -d tmp.o

tmp.o:     file format elf32-littleriscv

Disassembly of section .text:

00000000 <.text>:
   0:   fff50513            add a0,a0,-1

This produces a 32-bit instruction, as requested. However when assembled with RV32IZca (an identical set of instructions):

$ /opt/riscv/corev/bin/riscv32-corev-elf-gcc -c -march=rv32i_zca tmp.S && /opt/riscv/corev/bin/riscv32-corev-elf-objdump -d tmp.o

tmp.o:     file format elf32-littleriscv

Disassembly of section .text:

00000000 <.text>:
   0:   157d                    add a0,a0,-1

This results in a 16-bit opcode, even though compressed instructions were disabled via .option norvc.

Version

I tested with the latest prebuilt toolchain, dated 8th November 2023 on https://www.embecosm.com/resources/tool-chain-downloads/#corev:

$ /opt/riscv/corev/bin/riscv32-corev-elf-gcc --version
riscv32-corev-elf-gcc ('corev-openhw-gcc-ubuntu2204-20230905') 13.0.1 20230313 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Why this is a bug

Since we don't have an explicit wide instruction prefix like Arm's .w suffix, ,option norvc is the only way of inhibiting instruction compression in the assembler. Examples of cases where you may want to do this:

• In contexts like interrupt vector tables, jump instructions may be expanded to word size so so that they have the correct architecturally-specified table offset
• When a function head falls through into another function, and both functions have their entry points word-aligned for performance, deliberately widening instructions can achieve alignment without inserting nops
• Computed branches may rely on forced-wide instructions to hand-calculate jr offsets in auipc; add; jr + imm sequences, which are faster than la (auipc + addi); add; jr
• The entry NOP for semihosting sequences is required to be uncompressed

I thought I'd raise an issue because this seems like it might have been an oversight caused by C vs Zca confusion, rather than a deliberate change in behaviour. Please let me know if this was the wrong place to raise this. RV32IC and RV32IZca are identical instruction sets, so it is at least surprising that assembling the same file will give two different results.

[pz9115]

Thanks for your report, fix this in https://github.com/openhwgroup/corev-binutils-gdb/pull/108

[MaryBennett]

Thank you for your issue. The PR fixing this issue has just been merged in. I'm closing this issue.