PNaCl docs: Fix links to '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 41 matching lines @@
 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. Accessing atomic memory location through
-non-atomic primitives is `Undefined Behavior <undefined_behavior>`.
+non-atomic primitives is :ref:`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 122 matching lines @@
 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>`.
+discussed in :ref:`PNaCl Undefined Behavior <undefined_behavior>`.
 
 Floating-Point
 ==============
 
 PNaCl exposes 32-bit and 64-bit floating point operations which are
 mostly IEEE-754 compliant. There are a few caveats:
 
 * Some :ref:`floating-point behavior is currently left as undefined
   <undefined_behavior_fp>`.
 * The default rounding mode is round-to-nearest and other rounding modes
@@ skipping 72 matching lines @@
   A similar feature is **thread suspension**: The ability to
   asynchronously suspend and resume a thread and inspect or modify its
   execution state (such as register state).
 
   Neither PNaCl nor NaCl currently support asynchronous interruption
   or suspension of threads.
 
 If PNaCl were to support either of these, the interaction of
 ``volatile`` and atomics with same-thread signal handling would need
 to be carefully detailed.