Immediate values don't use the relocation, meaning lw with a number results in the wrong value passed to auipc.

[rsahwe]

lw t0 2 gets translated to auipc t0 2 and lw t0 2-pc t0 instead of auipc t0 0 and lw t0 2-pc t0.

This is because the relocation is only used with labels and not with regular immediates I think:

Ripes/src/isa/instruction.h

Lines 652 to 661 in 3a97948

	Reg_T_S value = getImm(immToken, success, convInfo);
	if (!success) {
	// Could not directly resolve immediate. Register it as a symbol to link
	// to.
	linksWithSymbol.resolveSymbol = applySymbolResolution;
	linksWithSymbol.symbol = immToken;
	linksWithSymbol.relocation = immToken.relocation();
	return Result<>::def();
	}

Using an expression such as (2 + 0) works correctly.

[NLS-04]

The behavior you observed is indeed incorrect, but not in the way you might expect.
What exactly are you intending to express by writing lw t0, 2? It appears that you are attempting to use a numeric immediate as an absolute address from which to load.

However, after consulting the GNU assembler documentation, the RISC-V Assembly Programmer’s Manual, and the official riscv-opcodes specification, I could not find any documented form in which absolute addressing via an explicit numeric immediate is supported nor excluded.

Regarding the pseudo instruction:

l{b|h|w|d} rd, symbol

which expands into:

auipc rd, symbol[31:12]
l{b|h|w|d} rd, symbol[11:0](rd)

If we apply that pseudo instruction definition strictly, then only symbols should in theory trigger the pseudo instruction expansion.
Unless we inplicitly declare immidiates to also be interpretable as symbols (which seems to be a logical conclusion for this case).

Therefore, to the best of my knowledge, the assembler behavior you describe is not a bug. On the contrary, the assembler should arguably not even accept this construct as valid input as of the current implementation of the assembler.

@mortbopet what do you think?

[NLS-04]

However, the current version of the implemented assembler allows you to do the following instead:

.equ A 2
lw t0, A

which when gets "correctly" (correctly in the sense of your reported issue) assembled to:

    0:        00000297        auipc x5 0x0
    4:        0022a283        lw x5 2 x5

Although this gets assembled to what you might expect it to, it is still considered invalided by the official RISC-V binutils 2.45.0: Error: illegal operands 'lw t0,A'

As long as we consider this a feature and not a bug, this should be fine for now.