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: <c578d5ac-ab8a-974a-bdd9-597b8c545583@redhat.com>
Date:   Wed, 1 Feb 2017 08:58:37 -0800
From:   Laura Abbott <labbott@...hat.com>
To:     Will Deacon <will.deacon@....com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     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>,
        Ard Biesheuvel <ard.biesheuvel@...aro.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 10/19/2016 09:22 AM, Will Deacon wrote:
> On Wed, Oct 19, 2016 at 09:01:33AM -0700, Linus Torvalds wrote:
>> On Wed, Oct 19, 2016 at 8:56 AM, Markus Trippelsdorf
>> <markus@...ppelsdorf.de> wrote:
>>> On 2016.10.19 at 08:55 -0700, Linus Torvalds wrote:
>>>>
>>>> Well, in the meantime we apparently have to live with it. Unless Will
>>>> is using some unreleased gcc version that nobody else is using and we
>>>> can just ignore it?
>>>
>>> Yes, he is using gcc-7 that is unreleased. (It will be released April
>>> next year.)
>>
>> Ahh, self-built? So it's not part of some experimental ARM distro
>> setup and this will be annoying lots of people?
> 
> Our friendly compiler guys built it, but it's just a snapshot of trunk,
> so it's all heading towards GCC 7.0. AFAIU, the problematic optimisation
> is also a mid-end pass, so it would affect other architectures too.
> 
>> If so, still think that we could just get rid of the ____ilog2_NaN()
>> thing as it's not _that_ important, but it's certainly not very
>> high-priority. Will can do it in his tree too for testing, and it can
>> remind people to get the gcc problem fixed.
> 
> I'm carrying the diff below, which fixes arm64 defconfig, but I'm worried
> that we might be relying on this trick elsewhere. The arm __bad_cmpxchg
> function, for example.
> 
> Will
> 
> --->8
> 
> diff --git a/include/linux/log2.h b/include/linux/log2.h
> index fd7ff3d91e6a..9cf5ad69065d 100644
> --- a/include/linux/log2.h
> +++ b/include/linux/log2.h
> @@ -16,12 +16,6 @@
>  #include <linux/bitops.h>
>  
>  /*
> - * deal with unrepresentable constant logarithms
> - */
> -extern __attribute__((const, noreturn))
> -int ____ilog2_NaN(void);
> -
> -/*
>   * non-constant log of base 2 calculators
>   * - the arch may override these in asm/bitops.h if they can be implemented
>   *   more efficiently than using fls() and fls64()
> @@ -85,7 +79,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
>  #define ilog2(n)				\
>  (						\
>  	__builtin_constant_p(n) ? (		\
> -		(n) < 1 ? ____ilog2_NaN() :	\
> +		(n) < 1 ? 0 :			\
>  		(n) & (1ULL << 63) ? 63 :	\
>  		(n) & (1ULL << 62) ? 62 :	\
>  		(n) & (1ULL << 61) ? 61 :	\
> @@ -149,9 +143,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
>  		(n) & (1ULL <<  3) ?  3 :	\
>  		(n) & (1ULL <<  2) ?  2 :	\
>  		(n) & (1ULL <<  1) ?  1 :	\
> -		(n) & (1ULL <<  0) ?  0 :	\
> -		____ilog2_NaN()			\
> -				   ) :		\
> +		0) :				\
>  	(sizeof(n) <= 4) ?			\
>  	__ilog2_u32(n) :			\
>  	__ilog2_u64(n)				\
> @@ -194,7 +186,6 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
>   * @n: parameter
>   *
>   * The first few values calculated by this routine:
> - *  ob2(0) = 0
>   *  ob2(1) = 0
>   *  ob2(2) = 1
>   *  ob2(3) = 2
> 

Reviving this thread as gcc 7 has now hit Fedora rawhide and has this
same issue. I pulled in the above patch from Will as a temporary work
around for building. It didn't look like there was consensus on a
permanent solution though from the thread.

Thanks,
Laura