Re: Compilation with clang

[David Brown]

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 to
> fix.
> 
> E.g. in avr/wdt.h there are several instances of code like this:
> 
>> static __inline__
>> __attribute__ ((__always_inline__))
>> void wdt_enable (const uint8_t value)
>> {
>>      if (_SFR_IO_REG_P (_WD_CONTROL_REG))
>>      {
>>              __asm__ __volatile__ (
>>                              [...]
>>                              : /* no outputs */
>>                              : "I" (_SFR_IO_ADDR(_WD_CONTROL_REG)),
>>                              [...]
>>                              : "r0"
>>              );
>>      }
>>      else {
>>              /* variant not using _WD_CONTROL_REG as immediate */
>>              [...]       
>>       
>> }
> 
> For targets where _SFR_IO_REG_P (_WD_CONTROL_REG) evaluates to false, the
> inline assembly in the then-clause is syntactically not correct, as the
> constraints "I" are not fulfilled. But GCC will never check the constraints,
> because GCC eliminates the dead branches prior to verifying correctness of
> inline assembly. With clang these syntax checks are done prior to the
> optimization of dead branches. I'm aware that inline assembly isn't part of 
> the
> C language, still performing syntax checks prior to the optimizations seems
> more consistent to me. (If there were C syntax errors in the dead branch, the
> compiler would also refuse to compile despite the lines in question being
> unreachable.)
> 

It's been a /long/ time since I have done anything with the AVR, and I
don't have a modern avr gcc compiler (or any clang avr compiler at all)
handy for testing.  However, I have an idea you can try:

        "I" (_SFR_IO_ADDR(_WD_CONTROL_REG) || 1)

If "_SFR_IO_ADDR(_WD_CONTROL_REG)" evaluates to false, then this
expression would give "1", which clang might be happier with.