Re: linux-next: build failure after merge of the arm tree

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Fri, May 03, 2024 at 09:18:01AM +0100, Russell King (Oracle) wrote:
> On Fri, May 03, 2024 at 10:15:16AM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the arm tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > drivers/clk/clkdev.c: In function 'vclkdev_alloc':
> > drivers/clk/clkdev.c:195:16: error: assignment to '__va_list_tag (*)[1]' from incompatible pointer type '__va_list_tag **' [-Werror=incompatible-pointer-types]
> >   195 |         fmt.va = ≈
> >       |                ^
> > cc1: all warnings being treated as errors
> 
> This builds perfectly fine for me - this is on debian stable with
> arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110:
> 
>   CC      drivers/clk/clkdev.o
>   AR      drivers/clk/built-in.a
>   AR      drivers/built-in.a
>   AR      built-in.a
>   AR      vmlinux.a
>   LD      vmlinux.o
>   OBJCOPY modules.builtin.modinfo
>   GEN     modules.builtin
>   MODPOST Module.symvers
>   UPD     include/generated/utsversion.h
>   CC      init/version-timestamp.o
>   LD      .tmp_vmlinux.kallsyms1
>   NM      .tmp_vmlinux.kallsyms1.syms
>   KSYMS   .tmp_vmlinux.kallsyms1.S
>   AS      .tmp_vmlinux.kallsyms1.S
>   LD      .tmp_vmlinux.kallsyms2
>   NM      .tmp_vmlinux.kallsyms2.syms
>   KSYMS   .tmp_vmlinux.kallsyms2.S
>   AS      .tmp_vmlinux.kallsyms2.S
>   LD      vmlinux
>   NM      System.map
> 
> No warnings, no errors.
> 
> va_format is defined as:
> 
> struct va_format {
>         const char *fmt;
>         va_list *va;
> };
> 
> and what we have here is a "va_list ap".
> 
> Therefore, the assignment:
> 
>         fmt.va = ≈
> 
> is correct.
> 
> What certainly won't work is:
> 
> 	fmt.va = ap;
> 
> and there aren't any other reasonable alternatives.
> 
> My conclusion: your compiler is being stupid.

... and even more evidence that your error is strange:

void __ext4_error(struct super_block *sb, const char *function,
                  unsigned int line, bool force_ro, int error, __u64 block,
                  const char *fmt, ...)
{
        struct va_format vaf;
        va_list args;

                vaf.fmt = fmt;
                vaf.va = &args;

Now, looking at __ext4_error(), it seems that va_start()..va_end()
need to be around this - but why this oddity? None of the other printing
functions like vsnprintf() require it? Why do we have this pitfall?
Why isn't this oddity documented anywhere?

However, I don't see that lack of va_start() etc would cause a type
error.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!