public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: noloader@gmail.com, Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Subject: Re: Disable optimizations on one function (was: 'pragma optimize' ...)
Date: Thu, 16 Jul 2015 16:32:00 -0000	[thread overview]
Message-ID: <55A7DC77.2010005@gmail.com> (raw)
In-Reply-To: <CAH8yC8kU9JXSyFHrW9neztA4btnjXuxv+m3KyPWp84F=Y1Rv7A@mail.gmail.com>

On 07/15/2015 11:58 PM, Jeffrey Walton wrote:
>>> I have one more question related to the use of '#pragma GCC optimize'.
>>> I have a zeroizer that must execute due to Certification and
>>> Accreditation (C&A) requirements. When the zeroizer is removed as a
>>> dead store, the compiler folks usually say, "but you asked for
>>> optimizations...".
>>>
>>> If we cannot use '#pragma GCC optimize' to turn off the optimizer for
>>> a function, then how do we tell the compiler to *not* remove the code?
>>
>> It is hard to tell without seeing the code. But see noclone, noinline
>> entries at:
>> http://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
>>
>
> As a simplified example, imagine I have a function ClearAndFree:
>
>      void ClearAndFree(void* ptr, size_t n)
>      {
>          if(!ptr) return;
>
>          memset(ptr, 0x00, n);
>          free(ptr);
>      }
>
> We've seen these type of functions have the memset optimized away.

(This is why the memset_s function was added to the C standard.)

The call to memset is optimized away because GCC knows both its
semantics and those of free. To prevent the memset from being
optimized away you must make it "believe" the semantics could
be different. There are a number of ways to do that: compiling
the function with the -fno-builtin-memset option (or one it's
enabled by) is one. Another is by hiding the memset call somehow,
e.g., by calling the function via a pointer initialized outside
the calling function, or by calling the function from an asm
statement.

Martin

      parent reply	other threads:[~2015-07-16 16:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-16  5:58 Jeffrey Walton
2015-07-16  9:00 ` Andrew Haley
2015-07-16  9:40   ` Jeffrey Walton
2015-07-16  9:59     ` Andrew Haley
2015-07-16 10:05       ` Jeffrey Walton
2015-07-16 16:32 ` Martin Sebor [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=55A7DC77.2010005@gmail.com \
    --to=msebor@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=markus@trippelsdorf.de \
    --cc=noloader@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).