PNaCl documentation: add undefined behavior

native_client_sdk/src/doc/reference/pnacl-c-cpp-language-support.rst

 ============================
 PNaCl C/C++ Language Support
 ============================
 
 .. contents::
    :local:
    :backlinks: none
    :depth: 3
 
 Source language support
@@ skipping 31 matching lines @@
 The memory model offered by PNaCl relies on the same coding guidelines
 as the C11/C++11 one: concurrent accesses must always occur through
 atomic primitives (offered by `atomic intrinsics
 <PNaClLangRef.html#atomicintrinsics>`_), and these accesses must always
 occur with the same size for the same memory location. Visibility of
 stores is provided on a happens-before basis that relates memory
 locations to each other as the C11/C++11 standards do.
 
 Non-atomic memory accesses may be reordered, separated, elided or fused
 according to C and C++'s memory model before the pexe is created as well
-as after its creation.
+as after its creation. Accessing atomic memory location through
+non-atomic primitives is `Undefined Behavior <undefined_behavior>`.
 
 As in C11/C++11 some atomic accesses may be implemented with locks on
 certain platforms. The ``ATOMIC_*_LOCK_FREE`` macros will always be
 ``1``, signifying that all types are sometimes lock-free. The
 ``is_lock_free`` methods and ``atomic_is_lock_free`` will return the
 current platform's implementation at translation time. These macros,
 methods and functions are in the C11 header ``<stdatomic.h>`` and the
 C++11 header ``<atomic>``.
 
 The PNaCl toolchain supports concurrent memory accesses through legacy
@@ skipping 118 matching lines @@
 ``asm("":::"memory")``, which gets transformed to a sequentially
 consistent memory barrier (equivalent to ``__sync_synchronize()``). In
 PNaCl this barrier is only guaranteed to order ``volatile`` and atomic
 memory accesses, though in practice the implementation attempts to also
 prevent reordering of memory accesses to objects which may escape.
 
 NaCl supports a fairly wide subset of inline assembly through GCC's
 inline assembly syntax, with the restriction that the sandboxing model
 for the target architecture has to be respected.
 
+Undefined Behavior
+==================
+
+The C and C++ languages expose some undefined behavior which is
+discussed in `PNaCl Undefined Behavior <undefined_behavior>`.
+
 Future Directions
 =================
 
 SIMD
 ----
 
 PNaCl currently doesn't support SIMD. We plan to add SIMD support in the
 very near future.
 
 NaCl supports SIMD.
@@ skipping 36 matching lines @@
 ``volatile`` and atomics with same-thread signal handling would need
 to be carefully detailed.
 
 Computed ``goto``
 -----------------
 
 PNaCl currently doesn't support computed ``goto``, a non-standard
 extension to C used by some interpreters.
 
 NaCl supports computed ``goto``.