Hi Jörg,
> Well, since Clang aims to be a GCC replacement, it would probably be
> good if the AVR port of it supported the standard AVR-GCC names, too.
that's what I thought, too. I started to work on this and I believe overriding
void AVRAsmPrinter::emitStartOfAsmFile(Module &M) in class AVRAsmP
As Marian Buschsieweke wrote:
> So I guess for my application I know only have to teach clang the value of
> __tmp_reg__ (and maybe also a few other constants) to get it compiling :-)
Well, since Clang aims to be a GCC replacement, it would probably be
good if the AVR port of it supported the sta
Hi,
Glad I could help - it's always nice to get one's "good deed for the
day" over by morning coffee, and relax and do evil the rest of the day :-)
More importantly, I think clang is going to have to be taught about
__tmp_reg__ anyway, because it is used in many places by avrlibc and
inline
Hi David,
that is an excellent idea. The attached patch implements that idea (slightly
different) and almost makes clang happy. It know fails with:
> /usr/avr/include/avr/wdt.h:436:5: error: invalid operand for instruction
> "in __tmp_reg__,__SREG__" "\n\t"
>
On 13/10/2021 18:05, Marian Buschsieweke wrote:
> Hi together,
>
> parts of the avrlibc headers are not compatible with clang. (The use case is
> not to compile avrlibc itself with clang, but rather an application using
> a vanilla GCC compiled avrlibc.) However, the issues are not always trivial
As Marian Buschsieweke wrote:
> parts of the avrlibc headers are not compatible with clang. (The use case is
> not to compile avrlibc itself with clang, but rather an application using
> a vanilla GCC compiled avrlibc.) However, the issues are not always trivial to
> fix.
I seem to remember someo
Hi together,
parts of the avrlibc headers are not compatible with clang. (The use case is
not to compile avrlibc itself with clang, but rather an application using
a vanilla GCC compiled avrlibc.) However, the issues are not always trivial to
fix.
E.g. in avr/wdt.h there are several instances of
