[avr] Tools won't understand their own assembly code.

[sprintersb]

Compile the following C module with

> clang --target=avr -c -save-temps

int r25, x;
void foo (void)
{
    r25 = x;
}

This will throw 4 errors at you:

*.s:8:11: error: invalid operand for instruction
        lds     r24, x
                     ^
*.s:9:11: error: invalid operand for instruction
        lds     r25, x+1
                     ^
*.s:10:6: error: invalid operand for instruction
        sts     r25+1, r25
                ^
*.s:11:6: error: invalid operand for instruction
        sts     r25, r24
                ^

The generated assembly code is all fine:

foo:
	lds	r24, x
	lds	r25, x+1
	sts	r25+1, r25
	sts	r25, r24
	ret

• The 2nd operand of lds is an absolute address, hence legitimate operands are: symbol, symbol+offset or integer. Hence its obvious that x names a symbol, not a register.

• The 1st operand of sts is an absolute address, hence legitimate operands are: symbol, symbol+offset or integer. Hence its obvious that r25 in the 1st operand names a symbol, not a register.

The appropriate RELOCs are of type R_AVR_16 in all the cases.

[benshi001]

fixed by https://reviews.llvm.org/D140777

[benshi001]

fixed by 7a45b13

[sprintersb]

Let ma add that the same problem also occurs with [r]jmp and [r]call when they are targetting a symbol like r24 or x. Again, compile with -save-temps:

int r24 (void);
int x (void);

int main (void)
{
    return x() + r24();
}

x and r24 are symbols that are perfectly fine, and let me add that with AVR ISA, there is no ambiguitiy of which kind an operand is. In the case above, it's a symbol or symbol+offset or int (any absolute constant that's known at link time or earlier).

[benshi001]

ymbols that are perfectly fine, and let me add that with AVR ISA, the

This case is also fixed in the main branch. I have tested your new case with --save-temps and there is no failure report.