linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: labbott@redhat.com (Laura Abbott)
To: linux-arm-kernel@lists.infradead.org
Subject: Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness
Date: Wed, 1 Feb 2017 08:58:37 -0800	[thread overview]
Message-ID: <c578d5ac-ab8a-974a-bdd9-597b8c545583@redhat.com> (raw)
In-Reply-To: <20161019162222.GT9193@arm.com>

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@trippelsdorf.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

  reply	other threads:[~2017-02-01 16:58 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-17 18:38 Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness Will Deacon
2016-10-17 19:43 ` Ard Biesheuvel
2016-10-19 13:35   ` Will Deacon
2016-10-19 14:59     ` Ard Biesheuvel
2016-10-19 15:01       ` Ard Biesheuvel
2016-10-19 15:11         ` Arnd Bergmann
2016-10-19 15:27           ` Ard Biesheuvel
2016-10-19 15:44             ` Arnd Bergmann
2016-10-19 15:32           ` Gregory CLEMENT
2016-10-19 15:58     ` Russell King - ARM Linux
2016-10-19 15:37 ` Markus Trippelsdorf
2016-10-19 15:55   ` Linus Torvalds
2016-10-19 15:56     ` Markus Trippelsdorf
2016-10-19 16:00       ` Ard Biesheuvel
2016-10-19 16:01       ` Linus Torvalds
2016-10-19 16:22         ` Will Deacon
2017-02-01 16:58           ` Laura Abbott [this message]
2017-02-01 17:36             ` Ard Biesheuvel
2017-02-01 18:19               ` Ard Biesheuvel
2017-02-01 19:04                 ` Joe Perches
2017-02-01 19:31                   ` Ard Biesheuvel
2017-02-01 19:49                     ` Joe Perches
2017-02-01 19:53                       ` Ard Biesheuvel
2017-02-01 20:34                         ` Joe Perches
2017-02-01 21:11                           ` Ard Biesheuvel
2017-02-02  9:02                   ` Peter Zijlstra
2017-02-01 21:50               ` Laura Abbott
2017-02-02  9:17                 ` Ard Biesheuvel
2017-02-02 15:43                   ` Laura Abbott
2017-02-02 15:45                     ` Ard Biesheuvel

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=c578d5ac-ab8a-974a-bdd9-597b8c545583@redhat.com \
    --to=labbott@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 NNTP newsgroup(s).