Re: [PATCH] MIPS: Fix inline asm input/output type mismatch in checksum.h used with Clang

[Maciej W. Rozycki]

On Wed, 27 Jan 2021, Thomas Bogendoerfer wrote:

> > Fix the following build error when make M=samples/bpf used with Clang:
> > 
> >   CLANG-bpf  samples/bpf/sockex2_kern.o
> > In file included from samples/bpf/sockex2_kern.c:7:
> > In file included from ./include/uapi/linux/if_tunnel.h:7:
> > In file included from ./include/linux/ip.h:16:
> > In file included from ./include/linux/skbuff.h:28:
> > In file included from ./include/net/checksum.h:22:
> > ./arch/mips/include/asm/checksum.h:161:9: error: unsupported inline asm: input with type 'unsigned long' matching output with type '__wsum' (aka 'unsigned int')
> >         : "0" ((__force unsigned long)daddr),
> >                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 1 error generated.
> > 
> > This is a known issue on MIPS [1], the changed code can be compiled
> > successfully by both GCC and Clang.
> > 
> > [1] https://lore.kernel.org/linux-mips/CAG_fn=W0JHf8QyUX==+rQMp8PoULHrsQCa9Htffws31ga8k-iw@xxxxxxxxxxxxxx/
> > 
> > Signed-off-by: Tiezhu Yang <yangtiezhu@xxxxxxxxxxx>
> > ---
> >  arch/mips/include/asm/checksum.h | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> applied to mips-next.

 This is in a performance-critical path (otherwise it wouldn't have been 
in the form of inline assembly).  Has it been verified that it does not 
regress code quality with GCC?

 The semantics is clear here: output is in the same register as in input, 
but the register holds a different local variable in each case.  There's 
nothing odd about that and the variables can obviously be of a different 
type each; that's no different to register usage with code produced by the 
compiler directly itself from a high-level language.

 I seem to remember discussing the issue before, but I can't remember what 
the outcome has been WRT filing this as a Clang bug, and archives are not 
easily available at the moment (I know a mirror exists, but any old links 
are not relevant there).  Would someone be able to fill me in?

 I think ultimately with any critical piece where a Clang workaround does 
regress code produced with GCC we do want to go with `#ifdef __clang__' so 
that good use with GCC is not penalised on one hand and we know the places 
to revert changes at should Clang ever get fixed.

 Otherwise I'll start suspecting that Clang supporters try some kind of an 
unfair game to gain advantage over GCC, by modifying projects such that 
the competing compiler produces worse code than it could if Clang was not 
actively supported.

  Maciej