working draft N2798: is a memory fence a side effect?

I searched this group, but did not find an answer.
Is the following code snippet legal or is it undefined behavior?

void f(int, int);
extern int sharedVar;
int function fence(){
  atomic_thread_fence(memory_order_seq_cst);
  return 0;
}
f(fence(), sharedVar);

Background:
A prior execution of fence() potentially has an effect on what value
is read from sharedVar. From a physical standpoint, the call changes
the state of the program and, thus, is a (physical) side effect. The
working draft has been very strict so far banning unsequenced side
effects (1.9 paragraph 16), the wording has changed to even forbid
something like f(i=1,i=1).
On the other hand, the relevant text of 1.9 paragraph 13, where the
side effects of the program model are listed, has not changed since
2003, which might indicate that a new side effect like a memory fence
has not been introduced. And a fencing instruction could lie deep in
an external library making it difficult for a user to detect such a
conflict.
Does anybody know what the program model of the current working draft
says in this case?

Wolf Lammen

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]