From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness
Date: Wed, 19 Oct 2016 17:11:40 +0200 [thread overview]
Message-ID: <4333753.kxspqi1Miz@wuerfel> (raw)
In-Reply-To: <CAKv+Gu_wJWCtQGfQv2V_tNq+zygMzbassEa92c5sx90w0TW4vw@mail.gmail.com>
On Wednesday, October 19, 2016 4:01:58 PM CEST Ard Biesheuvel wrote:
> On 19 October 2016 at 15:59, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > On 19 October 2016 at 14:35, Will Deacon <will.deacon@arm.com> wrote:
> >> On Mon, Oct 17, 2016 at 08:43:19PM +0100, Ard Biesheuvel wrote:
> >>> On 17 October 2016 at 19:38, Will Deacon <will.deacon@arm.com> wrote:
> >
> > Yes, and that would be perfectly legal from a correctness point of
> > view, and would likely help performance as well. By using
> > __builtin_constant_p(), you are choosing to perform a build time
> > evaluation of an expression that would ordinarily be evaluated only at
> > runtime. This implies that you have to address undefined behavior at
> > build time rather than at runtime as well.
> >
> >>> If order_base_2() is not defined for input 0, it should BUG() in that
> >>> case, and the associated __builtin_unreachable() should prevent the
> >>> special version from being emitted. If order_base_2() is defined for input
> >>> 0, it should not invoke ilog2() with that argument, and the problem should
> >>> go away as well.
> >>
> >> I don't necessarily think it should BUG() if it's not defined for input
> >> 0; things like __ffs don't do that and we'd be introducing conditional
> >> checks for cases that should not happen. The comment above order_base_2
> >> does suggest that ob2(0) should return 0, but it can actually end up
> >> invoking ilog2(-1), which is obviously wrong.
> >>
> >> I could update the comment, but that doesn't fix the build issue.
> >>
> >
> > Fixing roundup_pow_of_two() [which is arguably incorrect]
>
> I just spotted the comment that says it is undefined. But that means
> it could legally return 1 for input 0, i suppose
I think having the link error in roundup_pow_of_two() is safer than
returning 1.
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;
+ }
}
}
Arnd
next prev parent reply other threads:[~2016-10-19 15:11 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 [this message]
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
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=4333753.kxspqi1Miz@wuerfel \
--to=arnd@arndb.de \
--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