[linux-next:master] BUILD REGRESSION 736ee37e2e8eed7fe48d0a37ee5a709514d478b3

[Luc Van Oostenryck]

On Fri, May 20, 2022 at 02:40:20PM +0200, Geert Uytterhoeven wrote:
> Hi Günter
> 
> On Thu, May 19, 2022 at 8:48 AM Guenter Roeck <linux at roeck-us.net> wrote:
> > This is getting tiresome. Every driver using outb() on m68k will
> > experience that "problem". As far as I can see, it is caused by
> >
> > #define out_8(addr,b) (void)((*(__force volatile u8 *) (unsigned long)(addr)) = (b))

Not directly related to the root cause but the cast on the LHS is over-complex.
*) If the types are correct, 'addr' should always be a 'u8 __iomem *'. Casting
   it to an unsigned long will throw away all type checking: pointers of
   any size, of any address space, any kind of integer, any scalar value will
   be silently be accepted.
*) Then, when casting an integer to a pointer '__force' is unneeded because
   it's meaningless (because the integer has no type info about the pointee).

The most correct way to write the above would be:
	static inline void out_8(u8 __iomem *addr, ... b)
	{
		*((__force volatile u8 *)addr) = b;
	}
this way, you can typecheck 'addr' (but maybe it's the idea/the argument is
not always type clean?).
Otherwise, if the cast to unsigned long is kept, '__force' can be removed.
 
> 
> Indeed.
> 
> For the sparse people:
> 
> The full error is:
> 
>         drivers/net/appletalk/cops.c:382:17: error: incompatible types
> in conditional expression (different base types):
>         drivers/net/appletalk/cops.c:382:17:    unsigned char
>         drivers/net/appletalk/cops.c:382:17:    void
> 
> Basically, sparse doesn't like "a ? b : c", if the return types of
> b and c don't match, even if the resulting value is not used.

Well, you know that the motivation for sparse was to be stricter than GCC.
In this case it's simply what is required by the standard:
	    
    n1570 (C11) 6.5.15
	One of the following shall hold for the second and third operands:
	— both operands have arithmetic type;
	— both operands have the same structure or union type;
	— both operands have void type;
	— both operands are pointers to qualified or unqualified versions
          of compatible types;
	— one operand is a pointer and the other is a null pointer constant; or
	— one operand is a pointer to an object type and the other is a
          pointer to a qualified or unqualified version of void.

Also, yes, the type checking is independent from the fact of being used
or not (because the type of an expression must be know before any kind
of processing can be done on its value).

> E.g. outb() on m68k:
> 
>     #define outb(val, port) (((port) < 1024 && ISA_TYPE ==
> ISA_TYPE_ENEC) ? isa_rom_outb((val), (port)) : isa_outb((val),
> (port)))
> 
> where isa_rom_outb() leads to rom_out_8() returning u8, while
> isa_outb() leads to the out_8() that includes the cast to void.
> 
> So the best solution seems to be to add more "(void)" casts, to e.g.
> rom_out_8() and friends?

I kinda think so, yes (I suppose that rom_out_8() is never used as
returning a non-void value). But in truth, I think it's the excessive use
of relatively complex macros that is the real problem (an using a conditional
expression not for its value but for its side-effects). Can't outb() be
written as something like:
	static inline void outb(....) {
		if (port < 1024 && ISA_TYPE == ISA_TYPE_ENEC)
			isa_rom_outb(val, port);
		else
			isa_outb(val, port);
	}

With this you have better type checking, no trickery, no need for extra
casts, no problems with double evaluation, it's more readable (to me), ...
But yes, I suppose it's not really simple to convert all this. Sorry for
no being more helpful.

Best regards,
-- Luc