Details
- Reviewers
MaskRay aykevl dylanmckay
Diff Detail
Event Timeline
There is an old solution in https://reviews.llvm.org/D117423. The concern over there is that AVR specific checks should be implemented in AVR toolchain specific files. And this patch obeys that.
I don't know the AVR specific thing but having this toolchain-specific diagnostic in the toolchain-specific file seems the right direction.
clang/lib/Driver/ToolChains/AVR.cpp | ||
---|---|---|
418 |
clang/lib/Driver/ToolChains/AVR.cpp | ||
---|---|---|
393 | Currently command clang xx.c --target=avr -mmcu=attiny40 leads to wrong assembly generated, so we temperarily disable the avrtiny family. Until https://github.com/llvm/llvm-project/issues/53459 is fixed. |
I do not know whether the complexity is justified. Rejecting some -mmcu= for C source files looks quite dubious. Does it really help users?
Bear in mind that all these complexity translates to clang executable size increase for other users (most people don't use AVR).
Actually I would like to make clang+llvm+lld fully compatible with gcc+binutils (functionality, ABI, quality, ...), and finally replace avr-gcc as Arduino's default toolchain. (https://www.arduino.cc/en/software, Arduino is a popular MCU platform for hardware prototype development & verification)
Even many avr-libc (https://www.nongnu.org/avr-libc/) developers are trying build it with clang.
If you think it is complex, we can remove the extreme check of -x assembler-with-cpp, which is rarely in a real world.
The other implementation (https://reviews.llvm.org/D117423) is abundoned, since we should not put AVR specified checks in the common code in Clang.cpp.
@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 for details.
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:
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.
Currently command clang xx.c --target=avr -mmcu=attiny40 leads to wrong assembly generated, so we temperarily disable the avrtiny family. Until https://github.com/llvm/llvm-project/issues/53459 is fixed.