Re: About the clang/llvm tool chain for AVR

[Georg-Johann Lay]

> I am current maintainer of the llvm-avr backend, and I would like to ask
> for your feedback on my work. My final goal is making
> clang-llvm-lld-compiler_rt chain fully functional, and let AVR program
> developers get rid of the GNU tool chain. So any complain/concern/report
> is welcome.

As you are asking for feedback, here are my 4 points:

1. As far as I know, clang is using (parts of) avr-gcc installations.
When clang/llvm want to stand on its own feet, the tools should be
self-containing instead of parasitic.

2. There is no equivalent of attribute progmem.  You may argue that
clang has attribute address_space which is superior to progmem.
This is true but misses the point:  When users are supposed to
switch tool chains, then the transition should be as seamless
as possible.  Just replacing progmem with address_space will raise
hundreds of warnings per project for thousands of developers.
I'd rather be not the one facing the storm which that would raise.

3. There are still lots of bugs, in particular at the low end (asm).
My impression is that the clang developers are not eating their own
dog food.  On the upside, bug are fixed in a timely manner, much faster
than the average avr-gcc bug.  But I have to admit that after a dozen
or so inline asm bugs, I lost interest in supporting or even just
bench-marking clang in projects.

4. AFAIK, clang cannot be used to build AVR-LibC.  How is that supposed
to work if clang wants to replace gcc, I don't see.

Finally, when clang is mature enough, it could be an IDE option for
users to pick, stay or revert as they please.  So IDE maintainers are
the right address, IMO.

Johann