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

Russell King (Oracle)
2024-05-03T08:23:43Z

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 = &ap;
> > | ^
> > 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 = &ap;
>
> 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!