[cfe-dev] Does a inline assembly or a memory barrier disable optimizations in a function

[Jeffrey Walton]

On Sun, Aug 2, 2015 at 1:26 PM, Richard Smith <metafoo at gmail.com> wrote:
> On Aug 2, 2015 9:43 AM, "Jeffrey Walton" <noloader at gmail.com> wrote:
>>
>> On Sun, Aug 2, 2015 at 11:49 AM, Reid Kleckner <rnk at google.com> wrote:
>> > That construct is just a memory barrier that applies to escaped objects.
>> > Dead stores to unescaped locals for example will be removed during SSA
>> > conversion.
>> >
>> OK, thanks. That should probably be documented because its different
>> behavior from GCC.
>
> GCC's behavior is the same: https://goo.gl/R5AMDG

Thanks Richard.

That's actually quite interesting. I was recently inquired (again)
about this topic on the GCC mailing list, and one of the GCC devs told
me to use it.

The recommendation grew out of a conversation on trying to use
volatile to tame the optimize modulo Undefined Behavior (casting
tricks to/from T and volatile T) and Ian Lance' Taylor's blog on the
volatile keyword (http://www.airs.com/blog/archives/154). Taylor's
blog is important because GCC will optimize away the stores on the
volatile objects _on occasion_, so its _not_ a complete remediation.

Complete remediations are important in security engineering. See, for
example, Saltzer and Schroeder's "The Protection of Information in
Computer Systems"
(https://www.acsac.org/secshelf/papers/protection_information.pdf).

Jeff