From: David Daney <ddaney.cavm@gmail.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Pinski, Andrew" <Andrew.Pinski@caviumnetworks.com>,
Ralf Baechle <ralf@linux-mips.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
David Howells <dhowells@redhat.com>,
Markos Chandras <Markos.Chandras@imgtec.com>,
"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
John Crispin <blogic@openwrt.org>
Subject: Re: Issue with BUG() in asm-gemeric/bug.h if CONFIG_BUG=n
Date: Mon, 30 Sep 2013 12:17:47 -0700 [thread overview]
Message-ID: <5249CE5B.7040505@gmail.com> (raw)
In-Reply-To: <CAMuHMdXkb6BH=1QvfHwMN54db9mP64KnCgoAj3aXida7-6OtPA@mail.gmail.com>
On 09/30/2013 12:03 PM, Geert Uytterhoeven wrote:
> On Mon, Sep 30, 2013 at 7:45 PM, David Daney <ddaney.cavm@gmail.com> wrote:
>>> What about using __builtin_unreachable when we can but turn off warnings
>>> and use do{}while(0) when __builtin_unreachable does not exist? This seems
>>> the both worlds. Newer compilers produce better code with unreachable
>>> anyways.
>>>
>>
>> Simply not true.
>>
>> do{}while(0) is a NOP it is no more useful than an ';' statement. It
>> doesn't serve as a magic uninitialized variable hiding mechanism.
>
> You missed the "turn off warnings" part of the "and".
You are correct, I did miss it.
The real problem here is that the kernel is written to expect that BUG()
never returns. Any implementation that has BUG() return, is almost
certainly *not* what we want.
But wieh people select CONFIG_BUG=n they expect the smallest possible code.
These two criteria are mutually exclusive, so something should change.
It is not just the uninitialized variable warning, there can be others
as well (control reaching the end of a non-void function comes to mind).
So I don't think turning off the warnings is a good solution.
That leaves:
1) Remove CONFIG_BUG and make it unconditionally enabled.
2) Make CONFIG_BUG=n imply "static inline void BUG(void){do{}while(1);}"
which might be bigger than with CONFIG_BUG=y
David Daney
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
>
prev parent reply other threads:[~2013-09-30 19:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-30 14:56 Issue with BUG() in asm-gemeric/bug.h if CONFIG_BUG=n Ralf Baechle
2013-09-30 15:53 ` David Daney
2013-09-30 17:15 ` Pinski, Andrew
2013-09-30 17:45 ` David Daney
2013-09-30 19:03 ` Geert Uytterhoeven
2013-09-30 19:17 ` David Daney [this message]
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=5249CE5B.7040505@gmail.com \
--to=ddaney.cavm@gmail.com \
--cc=Andrew.Pinski@caviumnetworks.com \
--cc=Markos.Chandras@imgtec.com \
--cc=arnd@arndb.de \
--cc=blogic@openwrt.org \
--cc=dhowells@redhat.com \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.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