linux-kernel - Re: Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKv+Gu-+cSE8p1uhhgf7Sh+Ms8NmO=fe9Md9X1YSVgYWD3RO9A@mail.gmail.com>
Date:   Wed, 1 Feb 2017 21:11:37 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Joe Perches <joe@...ches.com>
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 1 February 2017 at 20:34, Joe Perches <joe@...ches.com> wrote:
> 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?
>

Why wouldn't it make sense?

In any case, we could also solve this by doing this instead

#define order_base_2(n)                        \
(                                              \
       __builtin_constant_p(n) ? (             \
               ((n) == 0 || (n) == 1) ? 0 :    \
               ilog2((n) - 1) + 1) :           \
       __order_base_2(n)                       \
)

which will emit the usual unresolveable __ilog2_NaN reference when
constants < 0 are passed to order_base_2()