From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: build failure after merge of the arm tree
Date: Fri, 3 May 2024 13:29:49 +0100 [thread overview]
Message-ID: <ZjTYvarXbn5eVPFT@shell.armlinux.org.uk> (raw)
In-Reply-To: <20240503220826.48a59ffd@canb.auug.org.au>
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)" <linux@armlinux.org.uk> 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!
next prev parent reply other threads:[~2024-05-03 12:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 0:15 linux-next: build failure after merge of the arm tree Stephen Rothwell
2024-05-03 8:18 ` Russell King (Oracle)
2024-05-03 8:23 ` Russell King (Oracle)
2024-05-03 12:08 ` Stephen Rothwell
2024-05-03 12:29 ` Russell King (Oracle) [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-08-31 9:10 Stephen Rothwell
2022-08-31 9:14 ` Matija Glavinic Pecotic
2021-10-25 23:25 Stephen Rothwell
2020-01-19 21:24 Stephen Rothwell
2020-01-19 21:31 ` Stephen Rothwell
2020-01-19 22:02 ` Russell King - ARM Linux admin
2017-04-20 22:40 Stephen Rothwell
2017-04-21 7:58 ` Mason
2017-04-21 8:12 ` Stephen Rothwell
2017-04-21 8:30 ` Mason
2017-04-21 23:43 ` Russell King - ARM Linux
2017-04-22 8:41 ` Mason
2017-04-24 4:20 ` Vinod Koul
2017-06-14 19:23 ` Mason
2017-04-21 11:27 ` Mason
2015-05-29 1:09 Stephen Rothwell
2014-04-10 1:35 Stephen Rothwell
2011-03-02 14:13 Stephen Rothwell
2011-03-02 15:55 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZjTYvarXbn5eVPFT@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).