include: Fix inline asm register constraints for clang

[beakthoven]

fixes errors like:

pgmspace.h:1084:41: error: unknown register name '30' in asm
 1084 |          : "+r" (__r24) : "r" (__r22) : "30", "31");

[sprintersb]

IMO it's pointless try to support llvm since it is not compatible to gcc. I performed quite some digging for the 2.3 release, and AVR-LibC is only compatible with GCC 4.8 or newer (or compilers compatible to that, which llvm isn't). You can't even configure AVR-LibC with llvm. Since libc depends on configure, libc can only be used with the tools for which it has been configured and built.

[beakthoven]

IMO it's pointless try to support llvm since it is not compatible to gcc. I performed quite some digging for the 2.3 release, and AVR-LibC is only compatible with GCC 4.8 or newer (or compilers compatible to that, which llvm isn't). You can't even configure AVR-LibC with llvm. Since libc depends on configure, libc can only be used with the tools for which it has been configured and built.

I'm not trying to make AVR-Libc compile with clang for now because the incompatibilities are pretty much obvious. I'm making AVR programs compile with clang against a existing GCC built AVR-Libc which IMO is fine, just like with glibc and clang. The headers just need some fixes to be useable with clang.

The rN form is already used widely elsewhere in the codebase eg:

avr-libc/include/ctype.h

Line 93 in 41441ba

register int __r24 __asm("r24") = __c;

avr-libc/include/util/ram-usage.h

Line 96 in 41441ba

register uint16_t __r24 __asm("r24");

So even if we ignore LLVM entirely, this patch simply just makes the headers more consistent with the rest of the codebase, with no behavioral change for GCC.

PS: Regarding the libc depending on configure, I'll be looking to address the incompatibilities either via patches to AVR-Libc or to LLVM itself whichever seems more appropriate.