[PATCH] D118095: [clang][AVR] Reject non assembly source files for the avr1 family

Sat Mar 26 00:12:53 PDT 2022

benshi001 added a comment.

In D118095#3408037 <https://reviews.llvm.org/D118095#3408037>, @aykevl wrote:

> @MaskRay it was my suggestion to move this from the toolchain specific file to the generic file, because it makes the implementation much simpler. See my comment D117423#3251110 <https://reviews.llvm.org/D117423#3251110> for details.
>
> In D118095#3282039 <https://reviews.llvm.org/D118095#3282039>, @MaskRay wrote:
>
>> Rejecting some -mmcu= for C source files looks quite dubious. Does it really help users?
>
> For context: the avr1 family isn't supported by avr-gcc either. It's a old and rather limited subset of the AVR instruction set. I assume it's going to be rather difficult (and not worth the trouble) to write a C compiler for it, as it doesn't even have a fully functional stack. From Wikipedia <https://en.m.wikipedia.org/wiki/Atmel_AVR_instruction_set>:
>
>> The AVR1 subset was not popular and no new models have been introduced since 2000. It omits all RAM except for the 32 registers mapped at address 0–31 and the I/O ports at addresses 32–95. The stack is replaced by a 3-level hardware stack, and the PUSH and POP instructions are deleted. All 16-bit operations are deleted, as are IJMP, ICALL, and all load and store addressing modes except indirect via Z.
>
> So I think the idea is to disallow this family so that users won't accidentally try to use a C compiler for these chips. However, writing assembly might still make sense.

My opinion is: we indeed need to be compatible with avr-gcc (accept assembly but reject c progarms), but we do it in AVR specific files and let common code clean.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118095/new/

https://reviews.llvm.org/D118095