[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1485981241.2560.20.camel@perches.com>
Date: Wed, 01 Feb 2017 12:34:01 -0800
From: Joe Perches <joe@...ches.com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Laura Abbott <labbott@...hat.com>,
Will Deacon <will.deacon@....com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Markus Trippelsdorf <markus@...ppelsdorf.de>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>, james.greenhalgh@....com,
Gregory Clement <gregory.clement@...e-electrons.com>,
Stephen Boyd <sboyd@...eaurora.org>
Subject: Re: Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness
On Wed, 2017-02-01 at 19:53 +0000, Ard Biesheuvel wrote:
> On 1 February 2017 at 19:49, Joe Perches <joe@...ches.com> wrote:
[]
> > Or maybe add a BUILD_BUG_ON something like:
> >
> > #define order_base_2(n) \
> > ({ \
> > typeof(n) _n = n; \
> > BUILD_BUG_ON(__builtin_constant_p(_n) && _n < 0); \
> > __builtin_constant_p(_n) ? (_n < 2 ? _n : ilog2((_n) - 1) + 1)) \
> > : __order_base_2(_n); \
> > })
> >
>
> This would interfere with the ability to use order_base_2() in
> initializers for global variables.
There aren't any as far as I can tell and would using
order_base_2() for a global initializer make sense?
Powered by blists - more mailing lists