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
Caused by commit
5d998425e37b ("clkdev: report over-sized strings when creating clkdev entries")
I have used the arm tree from next-20240502 for today.
--
Cheers,
Stephen Rothwell
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.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
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!
Hi Russell,
On Fri, 3 May 2024 09:18:00 +0100 "Russell King (Oracle)" <[email protected]> wrote:
>
> On Fri, May 03, 2024 at 10:15:16AM +1000, Stephen Rothwell wrote:
> >
> > 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:
>
> 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.
Definitely possible. My build is an x86_64 allmodconfig cross build
hosted on PowerPC64LE.
$ x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 13.2.0-7) 13.2.0
It still fails for me even just building your tree. :-(
And if I revert commit 5d998425e37b it does not fail (of course).
--
Cheers,
Stephen Rothwell
On Fri, May 03, 2024 at 10:08:26PM +1000, Stephen Rothwell wrote:
> Hi Russell,
>
> On Fri, 3 May 2024 09:18:00 +0100 "Russell King (Oracle)" <[email protected]> wrote:
> >
> > On Fri, May 03, 2024 at 10:15:16AM +1000, Stephen Rothwell wrote:
> > >
> > > 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:
> >
> > 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.
>
> Definitely possible. My build is an x86_64 allmodconfig cross build
> hosted on PowerPC64LE.
>
> $ x86_64-linux-gnu-gcc --version
> x86_64-linux-gnu-gcc (Debian 13.2.0-7) 13.2.0
>
> It still fails for me even just building your tree. :-(
>
> And if I revert commit 5d998425e37b it does not fail (of course).
So I think the questions are...
1) why does this fail with this compiler?
2) why does this instance fail, when we have plenty of other instances
in the kernel doing the same thing? (grep vaf fs/)
I'm wrong about the va_start()/va_end() - those are done in the
caller, e.g. clkdev_create() does the va_start..va_end before
passing the va_list to vclkdev_create() which then passes it down
to vclkdev_alloc(). So it would be wrong to add another va_start()
in vclkdev_alloc().
The only thing I can think of doing is something like:
#ifdef CONFIg_X86_64
pr_error("%s:%s ID is greater than %zu\n",
"[compiler error - unreportable device]",
con_id, failure, max_size);
#else
{
struct va_format fmt;
fmt.fmt = dev_fmt;
fmt.va = ≈
pr_err("%pV:%s: %s ID is greater than %zu\n",
&fmt, con_id, failure, max_size);
}
#endif
kfree(cla);
return NULL;
which would be better than nothing... but really we shouldn't be
working around what looks to me like a compiler bug like this.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!