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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
