[Bug middle-end/72795] Missed optimization of external-linkage variables in presence of barriers

["peter at cordes dot ca" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72795

--- Comment #3 from Peter Cordes <peter at cordes dot ca> ---
Based on further discussion
(http://chat.stackoverflow.com/rooms/119045/discussion-between-a3f-and-peter-cordes),
the only bug (or feature?) here is that asm("":::"memory") doesn't count as a
reference for `y`.

i.e. the reason that asm statement works as a barrier is that it might read
`y`, but gcc will still optimize away `y` completely if the only explicit
reference in the translation unit are the stores in g().  This leads to a link
error for:

static int y;
int g() {
   y = 1; asm volatile("movl $5, y(%%rip)":::"memory");
   y = 2; return y;
}

// int gety(){ return y; }  // link error with this commented out, otherwise ok

This can be seen as a feature: It's probably not desirable for any "memory"
clobber to prevent optimizing away any static variables.

If  y  does exist in the asm output at all, I think gcc's behaviour as far as
making the y=1 and y=2 stores happen separately is correct.  If y exists at
all, its value in memory has to be up-to-date.