[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKwvOd=_mnxnG3cFb6qBhO5KLFxjrgsavoQ37asY3O1B4LLkwA@mail.gmail.com>
Date: Mon, 22 Oct 2018 12:56:37 -0700
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: bernd@...rovitsch.priv.at
Subject: Re: [PATCH 1/2] Compiler Attributes: add support for __fallthrough
(gcc >= 7.1)
On Mon, Oct 22, 2018 at 11:15 AM Bernd Petrovitsch
<bernd@...rovitsch.priv.at> wrote:
>
> Hi all!
>
> On 22/10/18 19:54, Nick Desaulniers wrote:
> > On Mon, Oct 22, 2018 at 10:50 AM Bernd Petrovitsch
> > <bernd@...rovitsch.priv.at> wrote:
> [...]
> >> PS: clang++ errors with "fallthrough annotation in unreachable code" if
> >> [[fallthrough]] is after an assert(). clang-devs there, please, the
> >> fallthrough doesn't really generated code (I hope;-).
> [...]
> > Can you send me a link to a simple reproducer in godbolt (godbolt.org)
> > and we'll take a look?
>
> Does https://godbolt.org/z/2Y4zIo do it - I'm a godbolt-newbie?
Moving the kernel folks to bcc, since we don't need to be discussing
C++ on LKML.
https://godbolt.org/z/B1fo9Z shows that this works as intended, for
cases that cannot be statically proven. I guess I'm looking for a
more realistic code sample to show why putting a `break;` statement
there is untenable?
>
> For
> ---- snip ----
> #include <cassert>
>
> int main(void)
> {
> switch (1) {
> default:
> assert(0);
> [[fallthrough]];
> case 1:
> ;
> }
> return 0;
> }
> ---- snip ----
> Just "clang++ -Wimplicit-fallthrough -Werror" it .....
>
> MfG,
> Bernd
> --
> "I dislike type abstraction if it has no real reason. And saving
> on typing is not a good reason - if your typing speed is the main
> issue when you're coding, you're doing something seriously wrong."
> - Linus Torvalds
--
Thanks,
~Nick Desaulniers
Powered by blists - more mailing lists