public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Will Deacon <will.deacon@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stephen Boyd <sboyd@codeaurora.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	james.greenhalgh@arm.com,
	Gregory CLEMENT <gregory.clement@free-electrons.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness
Date: Wed, 19 Oct 2016 17:44:36 +0200	[thread overview]
Message-ID: <2995302.b19MFEzy6p@wuerfel> (raw)
In-Reply-To: <CAKv+Gu_100mM7EvaxAMoZvnr1Ce_EC=wzYkB80AjUmBx9exkGQ@mail.gmail.com>

On Wednesday, October 19, 2016 4:27:51 PM CEST Ard Biesheuvel wrote:
> >
> > Why not turn it into a runtime warning in this driver?
> >
> > diff --git a/drivers/clk/mvebu/armada-37xx-periph.c b/drivers/clk/mvebu/armada-37xx-periph.c
> > index cecb0fdfaef6..711d1d9842cc 100644
> > --- a/drivers/clk/mvebu/armada-37xx-periph.c
> > +++ b/drivers/clk/mvebu/armada-37xx-periph.c
> > @@ -349,8 +349,10 @@ static int armada_3700_add_composite_clk(const struct clk_periph_data *data,
> >                         rate->reg = reg + (u64)rate->reg;
> >                         for (clkt = rate->table; clkt->div; clkt++)
> >                                 table_size++;
> > -                       rate->width = order_base_2(table_size);
> > -                       rate->lock = lock;
> > +                       if (!WARN_ON(table_size == 0)) {
> > +                               rate->width = order_base_2(table_size);
> > +                               rate->lock = lock;
> > +                       }
> >                 }
> >         }
> >
> 
> I guess Will is not looking for a way to fix the driver, but for a way
> to eliminate this issue entirely going forward.
>
> In general, I think the issue where constant folding results in
> ilog2() or other similar functions being called with invalid build
> time constant parameter values is simply something we have to deal
> with.
> 
> In this case, it is in fact order_base_2() that deviates from its
> documented behavior (as Will points out), and fixing /that/ should
> make this particular issue go away afaict.

Ah, right. I also noticed that order_base_2() is defined as
log2(1 << (log2(n-1)+1)), which seems a bit redundant.
Maybe we can simplify it to something like

#define order_base_2(n) ((n) <= 1) ? 0 : log2((n) - 1) + 1)

	Arnd

  reply	other threads:[~2016-10-19 15:46 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 [this message]
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
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=2995302.b19MFEzy6p@wuerfel \
    --to=arnd@arndb.de \
    --cc=ard.biesheuvel@linaro.org \
    --cc=gregory.clement@free-electrons.com \
    --cc=james.greenhalgh@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sboyd@codeaurora.org \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    /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