[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210720141101.78c1b8ba@cakuba>
Date: Tue, 20 Jul 2021 14:11:01 +0200
From: Jakub Kicinski <kuba@...nel.org>
To: Stephen Rothwell <sfr@...b.auug.org.au>,
Bjarni Jonasson <bjarni.jonasson@...rochip.com>,
Steen Hegelund <steen.hegelund@...rochip.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Lars Povlsen <lars.povlsen@...rochip.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Networking <netdev@...r.kernel.org>
Subject: Re: linux-next: build failure in Linus' tree
On Tue, 20 Jul 2021 16:45:31 +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 15 Jul 2021 09:50:32 +1000 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >
> > While compiling Linus' tree, a powerpc-allmodconfig build (and others)
> > with gcc 4.9 failed like this:
> >
> > drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c: In function 'ifh_encode_bitfield':
> > include/linux/compiler_types.h:328:38: error: call to '__compiletime_assert_431' declared with attribute error: Unsupported width, must be <= 40
> > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> > ^
> > include/linux/compiler_types.h:309:4: note: in definition of macro '__compiletime_assert'
> > prefix ## suffix(); \
> > ^
> > include/linux/compiler_types.h:328:2: note: in expansion of macro '_compiletime_assert'
> > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> > ^
> > drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c:28:2: note: in expansion of macro 'compiletime_assert'
> > compiletime_assert(width <= 40, "Unsupported width, must be <= 40");
> > ^
> >
> > Caused by commit
> >
> > f3cad2611a77 ("net: sparx5: add hostmode with phylink support")
> >
> > I guess this is caused by the call to ifh_encode_bitfield() not being
> > inlined.
>
> I am still getting these failures.
Bjarni, Steen, could you address this build failure ASAP?
We can't have a compile time asserts in static functions, if the code
is optimized for size chances are the function won't get inlined. clang
is pretty bad at propagating constants to compile time asserts, too.
Please remove this check, or refactor it to be done in a macro, or ..
Powered by blists - more mailing lists