public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: Julian Waters <tanksherman27@gmail.com>,
	Gabriel Ravier <gabravier@gmail.com>,
	gcc-help@gcc.gnu.org
Subject: Re: Avoid removing an if (false) statement and its corresponding branch
Date: Sun, 23 Jul 2023 18:53:30 +0200	[thread overview]
Message-ID: <a51aaa15-3571-9258-9add-8a7b30991a98@hesbynett.no> (raw)
In-Reply-To: <CAP2b4GNR3Yjy8ChJqajgeNQ+0ze1eY7gZV3R1Ej7nKqv0pJeaw@mail.gmail.com>

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-23 16: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 [this message]
2023-07-25  5:52       ` Julian Waters

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=a51aaa15-3571-9258-9add-8a7b30991a98@hesbynett.no \
    --to=david.brown@hesbynett.no \
    --cc=gabravier@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=tanksherman27@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).