Fix comment typo.

[oota-llvm.git] / docs / LangRef.html

diff --git a/docs/LangRef.html b/docs/LangRef.html
index 72bd76d2ae09a5ab8f3f60e595e1d5c533049816..94f3c3d75a89c02a235a2c68eaaaceee5df687f7 100644 (file)
--- a/docs/LangRef.html
+++ b/docs/LangRef.html
@@ -61,7 +61,7 @@
   <li><a href="#constants">Constants</a>
     <ol>
       <li><a href="#simpleconstants">Simple Constants</a></li>
-      <li><a href="#aggregateconstants">Aggregate Constants</a></li>
+      <li><a href="#complexconstants">Complex Constants</a></li>
       <li><a href="#globalconstants">Global Variable and Function Addresses</a></li>
       <li><a href="#undefvalues">Undefined Values</a></li>
       <li><a href="#constantexprs">Constant Expressions</a></li>
@@ -545,11 +545,23 @@ All Global Variables and Functions have one of the following types of linkage:
   </dd>
 
   <dt><tt><b><a name="linkage_externweak">extern_weak</a></b></tt>: </dt>
+
   <dd>The semantics of this linkage follow the ELF object file model: the
     symbol is weak until linked, if not linked, the symbol becomes null instead
     of being an undefined reference.
   </dd>
 
+  <dt><tt><b><a name="linkage_linkonce">linkonce_odr</a></b></tt>: </dt>
+  <dt><tt><b><a name="linkage_weak">weak_odr</a></b></tt>: </dt>
+  <dd>Some languages allow inequivalent globals to be merged, such as two
+    functions with different semantics.  Other languages, such as <tt>C++</tt>,
+    ensure that only equivalent globals are ever merged (the "one definition
+    rule" - <tt>odr</tt>).  Such languages can use the <tt>linkonce_odr</tt>
+    and <tt>weak_odr</tt> linkage types to indicate that the global will only
+    be merged with equivalent globals.  These linkage types are otherwise the
+    same as their non-<tt>odr</tt> versions.
+  </dd>
+
   <dt><tt><b><a name="linkage_external">externally visible</a></b></tt>:</dt>
 
   <dd>If none of the above identifiers are used, the global is externally
@@ -591,10 +603,10 @@ preventing a collision.  Since "<tt>main</tt>" and "<tt>puts</tt>" are
 external (i.e., lacking any linkage declarations), they are accessible
 outside of the current module.</p>
 <p>It is illegal for a function <i>declaration</i>
-to have any linkage type other than "externally visible", <tt>dllimport</tt>,
+to have any linkage type other than "externally visible", <tt>dllimport</tt>
 or <tt>extern_weak</tt>.</p>
-<p>Aliases can have only <tt>external</tt>, <tt>internal</tt> and <tt>weak</tt>
-linkages.</p>
+<p>Aliases can have only <tt>external</tt>, <tt>internal</tt>, <tt>weak</tt>
+or <tt>weak_odr</tt> linkages.</p>
 </div>
 
 <!-- ======================================================================= -->
@@ -1788,12 +1800,14 @@ the long double format on your target.  All hexadecimal formats are big-endian
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsection"><a name="aggregateconstants">Aggregate Constants</a>
+<div class="doc_subsection">
+<a name="aggregateconstants"> <!-- old anchor -->
+<a name="complexconstants">Complex Constants</a></a>
 </div>
 
 <div class="doc_text">
-<p>Aggregate constants arise from aggregation of simple constants
-and smaller aggregate constants.</p>
+<p>Complex constants are a (potentially recursive) combination of simple
+constants and smaller complex constants.</p>
 
 <dl>
   <dt><b>Structure constants</b></dt>
@@ -1947,15 +1961,9 @@ following is the syntax for constant expressions:</p>
   <i>really</i> dangerous!</dd>
 
   <dt><b><tt>bitcast ( CST to TYPE )</tt></b></dt>
-  <dd>Convert a constant, CST, to another TYPE. The size of CST and TYPE must be
-  identical (same number of bits). The conversion is done as if the CST value
-  was stored to memory and read back as TYPE. In other words, no bits change 
-  with this operator, just the type.  This can be used for conversion of
-  aggregate types to any aggregate type, as long as they have the same bit
-  width. Vector types may also be casted to and from any other type as long as
-  they have the same bit width. For pointers it is only valid to cast to
-  another pointer type.
-  </dd>
+  <dd>Convert a constant, CST, to another TYPE. The constraints of the operands
+      are the same as those for the <a href="#i_bitcast">bitcast
+      instruction</a>.</dd>
 
   <dt><b><tt>getelementptr ( CSTPTR, IDX0, IDX1, ... )</tt></b></dt>
 
@@ -2146,7 +2154,7 @@ return value.</p>
 <pre>
   ret i32 5                       <i>; Return an integer value of 5</i>
   ret void                        <i>; Return from a void function</i>
-  ret { i32, i8 } { i32 4, i8 2 } <i>; Return an aggregate of values 4 and 2</i>
+  ret { i32, i8 } { i32 4, i8 2 } <i>; Return a struct of values 4 and 2</i>
 </pre>
 
 <p>Note that the code generator does not yet fully support large
@@ -3626,11 +3634,13 @@ the LLVM code for the given testcase is equivalent to:</p>
   }
 </pre>
 
-<p>Note that it is undefined to access an array out of bounds: array and 
-pointer indexes must always be within the defined bounds of the array type.
-The one exception for this rule is zero length arrays.  These arrays are
-defined to be accessible as variable length arrays, which requires access
-beyond the zero'th element.</p>
+<p>Note that it is undefined to access an array out of bounds: array
+and pointer indexes must always be within the defined bounds of the
+array type when accessed with an instruction that dereferences the
+pointer (e.g. a load or store instruction).  The one exception for
+this rule is zero length arrays.  These arrays are defined to be
+accessible as variable length arrays, which requires access beyond the
+zero'th element.</p>
 
 <p>The getelementptr instruction is often confusing.  For some more insight
 into how it works, see <a href="GetElementPtr.html">the getelementptr