public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Julian Waters <tanksherman27@gmail.com>
To: David Brown <david.brown@hesbynett.no>, gcc-help@gcc.gnu.org
Subject: Re: Avoid removing an if (false) statement and its corresponding branch
Date: Tue, 25 Jul 2023 13:52:31 +0800	[thread overview]
Message-ID: <CAP2b4GOjQF+JwwRU+nnDai6B0WVAwaySpbd5fCLP=1a0w2xhFg@mail.gmail.com> (raw)
In-Reply-To: <a51aaa15-3571-9258-9add-8a7b30991a98@hesbynett.no>

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

Thanks for the reply, but the solution was right there all along...

if (volatile bool _ = false)

On Mon, Jul 24, 2023 at 12:53 AM David Brown <david.brown@hesbynett.no>
wrote:

> On 23/07/2023 16:27, Julian Waters via Gcc-help wrote:
> > I just tried it and it does work, even on O3, however I would like to
> avoid
> > allocating a variable if possible. It's a shame that gnu::used doesn't
> > seem to work with if statements (If anyone knows where to look in the
> > source code do tell me). But thanks for the suggestion nonetheless!
> >
>
> How about:
>
> static inline bool False(void) {
>      bool b = false;
>      asm volatile("" : "+r" (b));
>      return b;
> }
>
> Then use "if (False()) ..." instead of "if (false) ...".
>
> The generated overhead is going to be minimal, and no volatile variables
> are created.  It's also quite cool (IMHO) to have 100% portable inline
> assembly!
>
> mvh.,
>
> David
>
>
>
> > best regards,
> > Julian
> >
> > On Sun, Jul 23, 2023 at 10:14 PM Gabriel Ravier <gabravier@gmail.com>
> wrote:
> >
> >> On 7/23/23 14:45, Julian Waters via Gcc-help wrote:
> >>> Hi all,
> >>>
> >>> Is there a way to stop gcc from nuking an if (false) statement and the
> >>> corresponding branch from the compiled code for debugging purposes?
> >>> Even turning off all optimizations doesn't achieve this
> >>>
> >>> best regards,
> >>> Julian
> >>
> >> IMO the simplest way would be to define something like `static const
> >> volatile bool unoptimizable_false = false;` somewhere and use it in
> >> place of `false`, when you want to avoid the if statement being
> >> optimized out.
> >>
> >>
> >
>
>

      reply	other threads:[~2023-07-25  5:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-23 12:45 Julian Waters
2023-07-23 14:14 ` Gabriel Ravier
2023-07-23 14:27   ` Julian Waters
2023-07-23 16:53     ` David Brown
2023-07-25  5:52       ` Julian Waters [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='CAP2b4GOjQF+JwwRU+nnDai6B0WVAwaySpbd5fCLP=1a0w2xhFg@mail.gmail.com' \
    --to=tanksherman27@gmail.com \
    --cc=david.brown@hesbynett.no \
    --cc=gcc-help@gcc.gnu.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 read-only IMAP folder(s) and NNTP newsgroup(s).