The R13B03 release.OTP_R13B03

16 files changed, 2582 insertions, 0 deletions

diff --git a/lib/compiler/doc/html/.gitignore b/lib/compiler/doc/html/.gitignore
new file mode 100644
index 0000000000..e69de29bb2
--- /dev/null
+++ b/lib/compiler/doc/html/.gitignore
diff --git a/lib/compiler/doc/man3/.gitignore b/lib/compiler/doc/man3/.gitignore
new file mode 100644
index 0000000000..e69de29bb2
--- /dev/null
+++ b/lib/compiler/doc/man3/.gitignore
diff --git a/lib/compiler/doc/pdf/.gitignore b/lib/compiler/doc/pdf/.gitignore
new file mode 100644
index 0000000000..e69de29bb2
--- /dev/null
+++ b/lib/compiler/doc/pdf/.gitignore
diff --git a/lib/compiler/doc/src/Makefile b/lib/compiler/doc/src/Makefile
new file mode 100644
index 0000000000..ee41a7074f
--- /dev/null
+++ b/lib/compiler/doc/src/Makefile
@@ -0,0 +1,112 @@
+#
+# %CopyrightBegin%
+# 
+# Copyright Ericsson AB 1997-2009. All Rights Reserved.
+# 
+# The contents of this file are subject to the Erlang Public License,
+# Version 1.1, (the "License"); you may not use this file except in
+# compliance with the License. You should have received a copy of the
+# Erlang Public License along with this software. If not, it can be
+# retrieved online at http://www.erlang.org/.
+# 
+# Software distributed under the License is distributed on an "AS IS"
+# basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+# the License for the specific language governing rights and limitations
+# under the License.
+# 
+# %CopyrightEnd%
+#
+include $(ERL_TOP)/make/target.mk
+include $(ERL_TOP)/make/$(TARGET)/otp.mk
+
+# ----------------------------------------------------
+# Application version
+# ----------------------------------------------------
+include ../../vsn.mk
+VSN=$(COMPILER_VSN)
+APPLICATION=compiler
+
+# ----------------------------------------------------
+# Release directory specification
+# ----------------------------------------------------
+RELSYSDIR = $(RELEASE_PATH)/lib/$(APPLICATION)-$(VSN)
+
+# ----------------------------------------------------
+# Target Specs
+# ----------------------------------------------------
+XML_APPLICATION_FILES = ref_man.xml
+XML_REF3_FILES = compile.xml
+
+XML_PART_FILES = part_notes.xml part_notes_history.xml
+XML_CHAPTER_FILES = notes.xml notes_history.xml
+
+BOOK_FILES = book.xml
+
+GIF_FILES = \
+	warning.gif
+
+XML_FILES = \
+	$(BOOK_FILES) $(XML_CHAPTER_FILES) \
+	$(XML_PART_FILES) $(XML_REF3_FILES) $(XML_APPLICATION_FILES)
+
+# ----------------------------------------------------
+
+HTML_FILES = $(XML_APPLICATION_FILES:%.xml=$(HTMLDIR)/%.html) \
+	$(XML_PART_FILES:%.xml=$(HTMLDIR)/%.html)
+
+INFO_FILE = ../../info
+
+MAN3_FILES = $(XML_REF3_FILES:%.xml=$(MAN3DIR)/%.3)
+
+HTML_REF_MAN_FILE = $(HTMLDIR)/index.html
+
+TOP_PDF_FILE =  $(PDFDIR)/$(APPLICATION)-$(VSN).pdf
+
+# ----------------------------------------------------
+# FLAGS 
+# ----------------------------------------------------
+XML_FLAGS += 
+
+# ----------------------------------------------------
+# Targets
+# ----------------------------------------------------
+$(HTMLDIR)/%.gif: %.gif
+	$(INSTALL_DATA) $< $@
+
+docs: pdf html man
+
+$(TOP_PDF_FILE): $(XML_FILES)
+
+pdf: $(TOP_PDF_FILE)
+
+html: gifs $(HTML_REF_MAN_FILE)
+
+man: $(MAN3_FILES)
+
+gifs: $(GIF_FILES:%=$(HTMLDIR)/%)
+
+debug opt: 
+
+clean clean_docs:
+	rm -rf $(HTMLDIR)/*
+	rm -f $(MAN3DIR)/*
+	rm -f $(TOP_PDF_FILE) $(TOP_PDF_FILE:%.pdf=%.fo)
+	rm -f errs core *~ 
+
+# ----------------------------------------------------
+# Release Target
+# ---------------------------------------------------- 
+include $(ERL_TOP)/make/otp_release_targets.mk
+
+release_docs_spec: docs
+	$(INSTALL_DIR) $(RELSYSDIR)/doc/pdf
+	$(INSTALL_DATA) $(TOP_PDF_FILE) $(RELSYSDIR)/doc/pdf
+	$(INSTALL_DIR) $(RELSYSDIR)/doc/html
+	$(INSTALL_DATA) $(HTMLDIR)/* \
+		$(RELSYSDIR)/doc/html
+	$(INSTALL_DATA) $(INFO_FILE) $(RELSYSDIR)
+	$(INSTALL_DIR) $(RELEASE_PATH)/man/man3
+	$(INSTALL_DATA) $(MAN3DIR)/* $(RELEASE_PATH)/man/man3
+
+release_spec:
+
diff --git a/lib/compiler/doc/src/book.xml b/lib/compiler/doc/src/book.xml
new file mode 100644
index 0000000000..fc56a837d5
--- /dev/null
+++ b/lib/compiler/doc/src/book.xml
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE book SYSTEM "book.dtd">
+
+<book xmlns:xi="http://www.w3.org/2001/XInclude">
+  <header titlestyle="normal">
+    <copyright>
+      <year>1997</year><year>2009</year>
+      <holder>Ericsson AB. All Rights Reserved.</holder>
+    </copyright>
+    <legalnotice>
+      The contents of this file are subject to the Erlang Public License,
+      Version 1.1, (the "License"); you may not use this file except in
+      compliance with the License. You should have received a copy of the
+      Erlang Public License along with this software. If not, it can be
+      retrieved online at http://www.erlang.org/.
+    
+      Software distributed under the License is distributed on an "AS IS"
+      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+      the License for the specific language governing rights and limitations
+      under the License.
+    
+    </legalnotice>
+
+    <title>Compiler</title>
+    <prepared>Robert Virding</prepared>
+    <docno></docno>
+    <date>1997-05-02</date>
+    <rev>1.1.2</rev>
+    <file>book.sgml</file>
+  </header>
+  <insidecover>
+  </insidecover>
+  <pagetext>Compiler Application (COMPILER)</pagetext>
+  <preamble>
+    <contents level="2"></contents>
+  </preamble>
+  <applications>
+    <xi:include href="ref_man.xml"/>
+  </applications>
+  <releasenotes>
+    <xi:include href="notes.xml"/>
+  </releasenotes>
+  <listofterms></listofterms>
+  <index></index>
+</book>
+
diff --git a/lib/compiler/doc/src/compile.xml b/lib/compiler/doc/src/compile.xml
new file mode 100644
index 0000000000..c39c9b25eb
--- /dev/null
+++ b/lib/compiler/doc/src/compile.xml
@@ -0,0 +1,743 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE erlref SYSTEM "erlref.dtd">
+
+<erlref>
+  <header>
+    <copyright>
+      <year>1996</year><year>2009</year>
+      <holder>Ericsson AB. All Rights Reserved.</holder>
+    </copyright>
+    <legalnotice>
+      The contents of this file are subject to the Erlang Public License,
+      Version 1.1, (the "License"); you may not use this file except in
+      compliance with the License. You should have received a copy of the
+      Erlang Public License along with this software. If not, it can be
+      retrieved online at http://www.erlang.org/.
+    
+      Software distributed under the License is distributed on an "AS IS"
+      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+      the License for the specific language governing rights and limitations
+      under the License.
+    
+    </legalnotice>
+
+    <title>compile</title>
+    <prepared>Robert Virding</prepared>
+    <docno></docno>
+    <date>1996-11-04</date>
+    <rev>A</rev>
+    <file>compile.sgml</file>
+  </header>
+  <module>compile</module>
+  <modulesummary>Erlang Compiler</modulesummary>
+  <description>
+    <p>This module provides an interface to the standard Erlang
+      compiler. It can generate either a new file which contains
+      the object code, or return a binary which can be loaded directly.
+    </p>
+  </description>
+
+  <funcs>
+    <func>
+      <name>file(File)</name>
+      <fsummary>Compile a file</fsummary>
+      <desc>
+        <p>Is the same as
+	  <c>file(File, [verbose,report_errors,report_warnings])</c>.
+	</p>
+      </desc>
+    </func>
+
+    <func>
+      <name>file(File, Options) -> CompRet</name>
+      <fsummary>Compile a file</fsummary>
+      <type>
+        <v>CompRet = ModRet | BinRet | ErrRet</v>
+        <v>ModRet = {ok,ModuleName} | {ok,ModuleName,Warnings}</v>
+        <v>BinRet = {ok,ModuleName,Binary} | {ok,ModuleName,Binary,Warnings}</v>
+        <v>ErrRet = error | {error,Errors,Warnings}</v>
+      </type>
+      <desc>
+        <p>Compiles the code in the file <c>File</c>, which is an
+	  Erlang source code file without the <c>.erl</c> extension.
+	  <c>Options</c> determine the behavior of the compiler.</p>
+
+        <p>Returns <c>{ok,ModuleName}</c> if successful, or <c>error</c>
+	  if there are errors. An object code file is created if
+	  the compilation succeeds with no errors. It is considered
+	  to be an error if the module name in the source code is
+	  not the same as the basename of the output file.</p>
+
+        <p>Here follows first all elements of <c>Options</c> that in
+	  some way control the behavior of the compiler.</p>
+        <taglist>
+          <tag><c>basic_validation</c></tag>
+          <item>
+            <p>This option is fast way to test whether a module will
+	      compile successfully (mainly useful for code generators
+              that want to verify the code they emit). No code will
+	      generated. If warnings are enabled, warnings generated by
+	      the <c>erl_lint</c> module (such as warnings for unused
+	      variables and functions) will be returned too.</p>
+
+            <p>Use the <c>strong_validation</c> option to generate all
+	      warnings that the compiler would generate.</p>
+          </item>
+
+          <tag><c>strong_validation</c></tag>
+          <item>
+            <p>Similar to the <c>basic_validation</c> option, no code
+	      will be generated, but more compiler passes will be run
+	      to ensure also warnings generated by the optimization
+	      passes are generated (such as clauses that will not match
+	      or expressions that are guaranteed to fail with an
+	      exception at run-time).</p>
+          </item>
+
+          <tag><c>binary</c></tag>
+          <item>
+            <p>Causes the compiler to return the object code in a
+              binary instead of creating an object file. If successful,
+              the compiler returns <c>{ok,ModuleName,Binary}</c>.</p>
+          </item>
+
+          <tag><c>bin_opt_info</c></tag>
+          <item>
+            <p>The compiler will emit informational warnings about binary
+	    matching optimizations (both successful and unsuccessful).
+	    See the <em>Efficiency Guide</em> for further information.</p>
+          </item>
+
+          <tag><c>compressed</c></tag>
+          <item>
+            <p>The compiler will compress the generated object code,
+	    which can be useful for embedded systems.</p>
+          </item>
+
+          <tag><c>debug_info</c></tag>
+          <item>
+            <marker id="debug_info"></marker>
+            <p>Include debug information in the form of abstract code
+              (see
+              <seealso marker="erts:absform">The Abstract Format</seealso>
+              in ERTS User's Guide) in the compiled beam module. Tools
+	      such as Debugger, Xref and Cover require the debug
+              information to be included.</p>
+
+            <p><em>Warning</em>: Source code can be reconstructed from
+              the debug information. Use encrypted debug information
+              (see below) to prevent this.</p>
+
+            <p>See
+              <seealso marker="stdlib:beam_lib#debug_info">beam_lib(3)</seealso>
+              for details.</p>
+          </item>
+
+          <tag><c>{debug_info_key,KeyString}</c></tag>
+          <item></item>
+          <tag><c>{debug_info_key,{Mode,KeyString}}</c></tag>
+          <item>
+            <marker id="debug_info_key"></marker>
+            <p>Include debug information, but encrypt it, so that it
+              cannot be accessed without supplying the key. (To give
+              the <c>debug_info</c> option as well is allowed, but is
+              not necessary.) Using this option is a good way to always
+              have the debug information available during testing, yet
+              protect the source code.</p>
+            <p><c>Mode</c> is the type of crypto algorithm to be used
+              for encrypting the debug information. The default type --
+              and currently the only type -- is <c>des3_cbc</c>.</p>
+            <p>See
+              <seealso marker="stdlib:beam_lib#debug_info">beam_lib(3)</seealso>
+              for details.</p>
+          </item>
+
+          <tag><c>encrypt_debug_info</c></tag>
+          <item>
+            <marker id="encrypt_debug_info"></marker>
+            <p>Like the <c>debug_info_key</c> option above, except that
+	      the key will be read from an <c>.erlang.crypt</c> file.
+	    </p>
+
+	    <p>See
+              <seealso marker="stdlib:beam_lib#debug_info">beam_lib(3)</seealso>
+              for details.</p>
+          </item>
+
+          <tag><c>'P'</c></tag>
+          <item>
+            <p>Produces a listing of the parsed code after preprocessing
+	      and parse transforms, in the file
+	      <c><![CDATA[<File>.P]]></c>. No object file is produced.
+	    </p>
+          </item>
+
+          <tag><c>'E'</c></tag>
+          <item>
+            <p>Produces a listing of the code after all source code
+	      transformations have been performed, in the file
+	      <c><![CDATA[<File>.E]]></c>. No object file is produced.
+	    </p>
+          </item>
+
+          <tag><c>'S'</c></tag>
+          <item>
+            <p>Produces a listing of the assembler code in the file
+              <c><![CDATA[<File>.S]]></c>. No object file is produced.
+	    </p>
+          </item>
+
+          <tag><c>report_errors/report_warnings</c></tag>
+          <item>
+            <p>Causes errors/warnings to be printed as they occur.</p>
+          </item>
+
+          <tag><c>report</c></tag>
+          <item>
+            <p>This is a short form for both <c>report_errors</c> and
+              <c>report_warnings</c>.</p>
+          </item>
+
+          <tag><c>return_errors</c></tag>
+          <item>
+            <p>If this flag is set, then
+	      <c>{error,ErrorList,WarningList}</c> is returned when
+	      there are errors.</p>
+          </item>
+
+          <tag><c>return_warnings</c></tag>
+          <item>
+            <p>If this flag is set, then an extra field containing
+              <c>WarningList</c> is added to the tuples returned on
+              success.</p>
+          </item>
+
+          <tag><c>return</c></tag>
+          <item>
+            <p>This is a short form for both <c>return_errors</c> and
+              <c>return_warnings</c>.</p>
+          </item>
+
+	  <tag><c>verbose</c></tag>
+          <item>
+            <p>Causes more verbose information from the compiler
+              describing what it is doing.</p>
+          </item>
+
+	  <tag><c>{outdir,Dir}</c></tag>
+          <item>
+            <p>Sets a new directory for the object code. The current
+              directory is used for output, except when a directory
+              has been specified with this option.</p>
+          </item>
+
+	  <tag><c>export_all</c></tag>
+          <item>
+            <p>Causes all functions in the module to be exported.</p>
+          </item>
+
+	  <tag><c>{i,Dir}</c></tag>
+          <item>
+            <p>Add <c>Dir</c> to the list of directories to be searched
+              when including a file. When encountering an
+	      <c>-include</c> or <c>-include_dir</c> directive,
+	      the compiler searches for header files in the following
+	      directories:</p>
+            <list type="ordered">
+              <item>
+                <p><c>"."</c>, the current working directory of
+		  the file server;</p>
+              </item>
+              <item>
+                <p>the base name of the compiled file;</p>
+              </item>
+              <item>
+                <p>the directories specified using the <c>i</c> option.
+                  The directory specified last is searched first.</p>
+              </item>
+            </list>
+          </item>
+
+          <tag><c>{d,Macro}</c></tag>
+          <item></item>
+          <tag><c>{d,Macro,Value}</c></tag>
+          <item>
+            <p>Defines a macro <c>Macro</c> to have the value
+	      <c>Value</c>. The default is <c>true</c>).</p>
+          </item>
+
+	  <tag><c>{parse_transform,Module}</c></tag>
+          <item>
+            <p>Causes the parse transformation function
+              <c>Module:parse_transform/2</c> to be applied to the
+              parsed code before the code is checked for errors.</p>
+          </item>
+
+	  <tag><c>asm</c></tag>
+          <item>
+            <p>The input file is expected to be assembler code (default
+	      file suffix ".S"). Note that the format of assembler files
+              is not documented, and may change between releases - this
+              option is primarily for internal debugging use.</p>
+          </item>
+
+          <tag><c>no_strict_record_tests</c></tag>
+          <item>
+            <p>This option is not recommended.</p>
+
+	    <p>By default, the generated code for
+	      the <c>Record#record_tag.field</c> operation verifies that
+	      the tuple <c>Record</c> is of the correct size for
+	      the record and that the first element is the tag
+	      <c>record_tag</c>. Use this option to omit
+	      the verification code.</p>
+          </item>
+
+          <tag><c>no_error_module_mismatch</c></tag>
+          <item>
+            <p>Normally the compiler verifies that the module name
+	    given in the source code is the same as the base name
+	    of the output file and refuses to generate an output file
+	    if there is a mismatch. If you have a good reason (or
+	    other reason) for having a module name unrelated to the
+	    name of the output file, this option disables that verification
+	    (there will not even be a warning if there is a mismatch).</p>
+          </item>
+
+        </taglist>
+
+        <p>If warnings are turned on (the <c>report_warnings</c> option
+          described above), the following options control what type of
+          warnings that will be generated.
+	  <marker id="erl_lint_options"></marker>
+          With the exception of <c>{warn_format,Verbosity}</c> all
+	  options below have two forms; one <c>warn_xxx</c> form to
+	  turn on the warning and one <c>nowarn_xxx</c> form to turn off
+	  the warning. In the description that follows, the form that
+	  is used to change the default value is listed.</p>
+
+        <taglist>
+          <tag><c>{warn_format, Verbosity}</c></tag>
+          <item>
+            <p>Causes warnings to be emitted for malformed format
+              strings as arguments to <c>io:format</c> and similar
+              functions. <c>Verbosity</c> selects the amount of
+              warnings: 0 = no warnings; 1 = warnings for invalid
+              format strings and incorrect number of arguments; 2 =
+              warnings also when the validity could not be checked
+              (for example, when the format string argument is a
+              variable). The default verbosity is 1. Verbosity 0 can
+              also be selected by the option <c>nowarn_format</c>.</p>
+          </item>
+
+          <tag><c>nowarn_bif_clash</c></tag>
+          <item>
+            <p>By default, there will be a compilation error if a
+              module contains an exported function with the same name
+              as an auto-imported BIF (such as <c>size/1</c>) AND
+              there is a call to it without a qualifying module name.
+              The reason is that the BIF will be called, not
+	      the function in the same module. The recommended way to
+	      eliminate that warning is to use a call with a module
+	      name - either <c>erlang</c> to call the BIF or
+	      <c>?MODULE</c> to call the function in the same module.
+              The warning can also be turned off using this option,
+	      but that is not recommended.</p>
+
+	    <p><em>The use of this option is strongly discouraged,
+	    as code that uses it will probably break in a future
+	    major release (R14 or R15).</em></p>
+          </item>
+
+          <tag><c>{nowarn_bif_clash, FAs}</c></tag>
+          <item>
+            <p>Turns off warnings as <c>nowarn_bif_clash</c> but only
+	      for the mentioned local functions. <c>FAs</c> is a tuple
+	      <c>{Name,Arity}</c> or a list of such tuples.</p>
+	      <p><em>The use of this option is strongly discouraged,
+	      as code that uses it will probably break in a future
+	      major release (R14 or R15).</em></p>
+          </item>
+
+	  <tag><c>warn_export_all</c></tag>
+          <item>
+            <p>Causes a warning to be emitted if the <c>export_all</c>
+	      option has also been given.</p>
+          </item>
+
+	  <tag><c>warn_export_vars</c></tag>
+          <item>
+            <p>Causes warnings to be emitted for all implicitly
+              exported variables referred to after the primitives
+              where they were first defined. No warnings for exported
+              variables unless they are referred to in some pattern,
+              which is the default, can be selected by the option
+              <c>nowarn_export_vars</c>.</p>
+          </item>
+
+	  <tag><c>warn_shadow_vars</c></tag>
+          <item>
+            <p>Causes warnings to be emitted for "fresh" variables
+              in functional objects or list comprehensions with the same
+	      name as some already defined variable. The default is to
+	      warn for such variables. No warnings for shadowed
+	      variables can be selected by the option 
+              <c>nowarn_shadow_vars</c>.</p>
+          </item>
+
+	  <tag><c>nowarn_unused_function</c></tag>
+          <item>
+            <p>Turns off warnings for unused local functions.
+              By default (<c>warn_unused_function</c>), warnings are
+	      emitted for all local functions that are not called
+	      directly or indirectly by an exported function.
+              The compiler does not include unused local functions in
+	      the generated beam file, but the warning is still useful
+	      to keep the source code cleaner.</p>
+          </item>
+
+	  <tag><c>{nowarn_unused_function, FAs}</c></tag>
+          <item>
+            <p>Turns off warnings for unused local functions as
+              <c>nowarn_unused_function</c> but only for the mentioned
+              local functions. <c>FAs</c> is a tuple <c>{Name,Arity}</c>
+              or a list of such tuples.</p>
+          </item>
+
+	  <tag><c>nowarn_deprecated_function</c></tag>
+          <item>
+            <p>Turns off warnings for calls to deprecated functions. By
+	      default (<c>warn_deprecated_function</c>), warnings are
+	      emitted for every call to a function known by the compiler
+	      to be deprecated. Note that the compiler does not know
+	      about the <c>-deprecated()</c> attribute but uses an
+	      assembled list of deprecated functions in Erlang/OTP. To
+	      do a more general check the <c>Xref</c> tool can be used.
+	      See also
+	      <seealso marker="tools:xref#deprecated_function">xref(3)</seealso>
+              and the function
+	      <seealso marker="tools:xref#m/1">xref:m/1</seealso> also
+              accessible through
+	      the <seealso marker="stdlib:c#xm/1">c:xm/1</seealso>
+	      function.</p>
+          </item>
+
+	  <tag><c>{nowarn_deprecated_function, MFAs}</c></tag>
+          <item>
+            <p>Turns off warnings for calls to deprecated functions as
+	      <c>nowarn_deprecated_function</c> but only for
+	      the mentioned functions. <c>MFAs</c> is a tuple
+              <c>{Module,Name,Arity}</c> or a list of such tuples.</p>
+          </item>
+
+	  <tag><c>warn_obsolete_guard</c></tag>
+          <item>
+            <p>Causes warnings to be emitted for calls to old type
+	      testing BIFs such as <c>pid/1</c> and <c>list/1</c>. See
+	      the
+	      <seealso marker="doc/reference_manual:expressions#guards">Erlang Reference Manual</seealso>
+	      for a complete list of type testing BIFs and their old
+	      equivalents. No warnings for calls to old type testing
+	      BIFs, which is the default, can be selected by the option
+              <c>nowarn_obsolete_guard</c>.</p>
+          </item>
+
+	  <tag><c>warn_unused_import</c></tag>
+          <item>
+            <p>Causes warnings to be emitted for unused imported
+              functions. No warnings for unused imported functions,
+	      which is the default, can be selected by the option
+              <c>nowarn_unused_import</c>. </p>
+          </item>
+
+          <tag><c>nowarn_unused_vars</c></tag>
+          <item>
+            <p>By default, warnings are emitted for variables which
+              are not used, with the exception of variables beginning
+              with an underscore ("Prolog style warnings").
+              Use this option to turn off this kind of warnings.</p>
+          </item>
+
+	  <tag><c>nowarn_unused_record</c></tag>
+          <item>
+            <p>Turns off warnings for unused record types. By
+              default (<c>warn_unused_records</c>), warnings are
+              emitted for unused locally defined record types.</p>
+          </item>
+        </taglist>
+
+	<p>Another class of warnings is generated by the compiler
+	  during optimization and code generation. They warn about
+	  patterns that will never match (such as <c>a=b</c>), guards
+	  that will always evaluate to false, and expressions that will
+	  always fail (such as <c>atom+42</c>).</p>
+
+        <p>Note that the compiler does not warn for expressions that it
+          does not attempt to optimize. For instance, the compiler tries
+          to evaluate <c>1/0</c>, notices that it will cause an
+	  exception and emits a warning. On the other hand,
+	  the compiler is silent about the similar expression
+	  <c>X/0</c>; because of the variable in it, the compiler does
+	  not even try to evaluate and therefore it emits no warnings.
+	</p>
+
+	<p>Currently, those warnings cannot be disabled (except by
+	  disabling all warnings).</p>
+
+	<warning>
+          <p>Obviously, the absence of warnings does not mean that
+	    there are no remaining errors in the code.</p>
+        </warning>
+
+	<p>Note that all the options except the include path
+	  (<c>{i,Dir}</c>) can also be given in the file with a
+	  <c>-compile([Option,...])</c>. attribute.
+	  The <c>-compile()</c> attribute is allowed after function
+	  definitions.</p>
+
+	<p>Note also that the <c>{nowarn_unused_function, FAs}</c>,
+          <c>{nowarn_bif_clash, FAs}</c>, and 
+          <c>{nowarn_deprecated_function, MFAs}</c> options are only
+          recognized when given in files. They are not affected by
+	  the <c>warn_unused_function</c>, <c>warn_bif_clash</c>, or 
+          <c>warn_deprecated_function</c> options.</p>
+
+        <p>For debugging of the compiler, or for pure curiosity,
+          the intermediate code generated by each compiler pass can be
+	  inspected.
+          A complete list of the options to produce list files can be
+	  printed by typing <c>compile:options()</c> at the Erlang
+	  shell prompt.
+          The options will be printed in order that the passes are
+	  executed. If more than one listing option is used, the one
+	  representing the earliest pass takes effect.</p>
+
+        <p><em>Unrecognized options are ignored.</em></p>
+
+        <p>Both <c>WarningList</c> and <c>ErrorList</c> have
+	  the following format:</p>
+        <code>
+[{FileName,[ErrorInfo]}].
+        </code>
+
+	<p><c>ErrorInfo</c> is described below. The file name has been
+	  included here as the compiler uses the Erlang pre-processor
+	  <c>epp</c>, which allows the code to be included in other
+	  files. For this reason, it is important to know to
+	  <em>which</em> file an error or warning line number refers.
+	</p>
+      </desc>
+    </func>
+
+    <func>
+      <name>forms(Forms)</name>
+      <fsummary>Compile a list of forms</fsummary>
+      <desc>
+        <p>Is the same as
+	  <c>forms(File, [verbose,report_errors,report_warnings])</c>.
+	</p>
+      </desc>
+    </func>
+
+    <func>
+      <name>forms(Forms, Options) -> CompRet</name>
+      <fsummary>Compile a list of forms</fsummary>
+      <type>
+        <v>Forms = [Form]</v>
+        <v>CompRet = BinRet | ErrRet</v>
+        <v>BinRet = {ok,ModuleName,BinaryOrCode} | {ok,ModuleName,BinaryOrCode,Warnings}</v>
+        <v>BinaryOrCode = binary() | term()</v>
+        <v>ErrRet = error | {error,Errors,Warnings}</v>
+      </type>
+      <desc>
+        <p>Analogous to <c>file/1</c>, but takes a list of forms (in
+	  the Erlang abstract format representation) as first argument.
+          The option <c>binary</c> is implicit; i.e., no object code
+	  file is produced. Options that would ordinarily produce a
+	  listing file, such as 'E', will instead cause the internal
+	  format for that compiler pass (an Erlang term; usually not a
+	  binary) to be returned instead of a binary.</p>
+      </desc>
+    </func>
+
+    <func>
+      <name>format_error(ErrorDescriptor) -> chars()</name>
+      <fsummary>Format an error descriptor</fsummary>
+      <type>
+        <v>ErrorDescriptor = errordesc()</v>
+      </type>
+      <desc>
+        <p>Uses an <c>ErrorDescriptor</c> and returns a deep list of
+	  characters which describes the error. This function is
+	  usually called implicitly when an <c>ErrorInfo</c> structure
+	  is processed. See below.</p>
+      </desc>
+    </func>
+
+    <func>
+      <name>output_generated(Options) -> true | false</name>
+      <fsummary>Determine whether the compile will generate an output file</fsummary>
+      <type>
+        <v>Options = [term()]</v>
+      </type>
+      <desc>
+        <p>Determines whether the compiler would generate a <c>beam</c>
+	file with the given options. <c>true</c> means that a <c>beam</c>
+	file would be generated; <c>false</c> means that the compiler
+	would generate some listing file, return a binary, or merely
+	check the syntax of the source code.</p>
+      </desc>
+    </func>
+
+    <func>
+      <name>noenv_file(File, Options) -> CompRet</name>
+      <fsummary>Compile a file (ignoring ERL_COMPILER_OPTIONS)</fsummary>
+      <desc>
+      <p>Works exactly like <seealso marker="#file/2">file/2</seealso>,
+	 except that the environment variable <c>ERL_COMPILER_OPTIONS</c>
+	 is not consulted.</p>
+      </desc>
+    </func>
+
+    <func>
+      <name>noenv_forms(Forms, Options) -> CompRet</name>
+      <fsummary>Compile a list of forms (ignoring ERL_COMPILER_OPTIONS)</fsummary>
+      <desc>
+        <p>Works exactly like <seealso marker="#forms/2">forms/2</seealso>,
+	 except that the environment variable <c>ERL_COMPILER_OPTIONS</c>
+	 is not consulted.</p>
+      </desc>
+    </func>
+
+    <func>
+      <name>noenv_output_generated(Options) -> true | false</name>
+      <fsummary>Determine whether the compile will generate an output file (ignoring ERL_COMPILER_OPTIONS)</fsummary>
+      <type>
+        <v>Options = [term()]</v>
+      </type>
+      <desc>
+        <p>Works exactly like
+	<seealso marker="#output_generated/1">output_generated/1</seealso>,
+	except that the environment variable <c>ERL_COMPILER_OPTIONS</c>
+	is not consulted.</p>
+      </desc>
+    </func>
+
+  </funcs>
+
+  <section>
+    <title>Default compiler options</title>
+    <p>The (host operating system) environment variable
+      <c>ERL_COMPILER_OPTIONS</c> can be used to give default compiler
+      options. Its value must be a valid Erlang term. If the value is a
+      list, it will be used as is. If it is not a list, it will be put
+      into a list.</p>
+
+      <p>The list will be appended to any options given to
+      <seealso marker="#file/2">file/2</seealso>,
+      <seealso marker="#forms/2">forms/2</seealso>, and
+      <seealso marker="#output_generated/1">output_generated/2</seealso>.
+      Use the alternative functions
+      <seealso marker="#noenv_file/2">noenv_file/2</seealso>,
+      <seealso marker="#noenv_forms/2">noenv_forms/2</seealso>, or
+      <seealso marker="#noenv_output_generated/1">noenv_output_generated/2</seealso>
+      if you don't want the environment variable to be consulted
+      (for instance, if you are calling the compiler recursively from
+      inside a parse transform).</p>
+  </section>
+
+  <section>
+    <title>Inlining</title>
+    <p>The compiler can do function inlining within an Erlang
+      module. Inlining means that a call to a function is replaced with
+      the function body with the arguments replaced with the actual
+      values. The semantics are preserved, except if exceptions are
+      generated in the inlined code. Exceptions will be reported as
+      occurring in the function the body was inlined into. Also,
+      <c>function_clause</c> exceptions will be converted to similar
+      <c>case_clause</c> exceptions.</p>
+
+    <p>When a function is inlined, the original function will be
+      kept if it is exported (either by an explicit export or if the
+      <c>export_all</c> option was given) or if not all calls to the
+      function were inlined.</p>
+    
+    <p>Inlining does not necessarily improve running time.
+      For instance, inlining may increase Beam stack usage which will
+      probably be detrimental to performance for recursive functions.
+    </p>
+
+    <p>Inlining is never default; it must be explicitly enabled with a
+      compiler option or a <c>-compile()</c> attribute in the source
+      module.</p>
+
+    <p>To enable inlining, either use the <c>inline</c> option to
+    let the compiler decide which functions to inline or
+    <c>{inline,[{Name,Arity},...]}</c> to have the compiler inline
+    all calls to the given functions. If the option is given inside
+    a <c>compile</c> directive in an Erlang module, <c>{Name,Arity}</c>
+    may be written as <c>Name/Arity</c>.</p>
+
+    <p>Example of explicit inlining:</p>
+
+    <pre>
+-compile({inline,[pi/0]}).
+
+pi() -> 3.1416.
+    </pre>
+
+    <p>Example of implicit inlining:</p>
+    <pre>
+-compile(inline).
+    </pre>
+
+    <p>The <c>{inline_size,Size}</c> option controls how large functions
+      that are allowed to be inlined. Default is <c>24</c>, which will
+      keep the size of the inlined code roughly the same as
+      the un-inlined version (only relatively small functions will be
+      inlined).</p>
+
+    <p>Example:</p>
+    <pre>
+%% Aggressive inlining - will increase code size.
+-compile(inline).
+-compile({inline_size,100}).
+    </pre>
+  </section>
+
+  <section>
+    <title>Parse Transformations</title>
+
+    <p>Parse transformations are used when a programmer wants to use
+      Erlang syntax but with different semantics. The original Erlang
+      code is then transformed into other Erlang code.</p>
+  </section>
+
+  <section>
+    <title>Error Information</title>
+
+    <p>The <c>ErrorInfo</c> mentioned above is the standard
+      <c>ErrorInfo</c> structure which is returned from all IO modules.
+      It has the following format:</p>
+    <code>
+{ErrorLine, Module, ErrorDescriptor}
+    </code>
+
+    <p>A string describing the error is obtained with the following
+      call:</p>
+    <code>
+apply(Module, format_error, ErrorDescriptor)
+    </code>
+  </section>
+
+  <section>
+    <title>See Also</title>
+    <p>
+      <seealso marker="stdlib:epp">epp(3)</seealso>,
+      <seealso marker="stdlib:erl_id_trans">erl_id_trans(3)</seealso>,
+      <seealso marker="stdlib:erl_lint">erl_lint(3)</seealso>,
+      <seealso marker="stdlib:beam_lib">beam_lib(3)</seealso>
+    </p>
+  </section>
+</erlref>
+
diff --git a/lib/compiler/doc/src/fascicules.xml b/lib/compiler/doc/src/fascicules.xml
new file mode 100644
index 0000000000..43090b4aed
--- /dev/null
+++ b/lib/compiler/doc/src/fascicules.xml
@@ -0,0 +1,15 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE fascicules SYSTEM "fascicules.dtd">
+
+<fascicules>
+  <fascicule file="ref_man" href="ref_man_frame.html" entry="yes">
+    Reference Manual
+  </fascicule>
+  <fascicule file="part_notes" href="part_notes_frame.html" entry="no">
+    Release Notes
+  </fascicule>
+  <fascicule file="" href="../../../../doc/print.html" entry="no">
+    Off-Print
+  </fascicule>
+</fascicules>
+
diff --git a/lib/compiler/doc/src/make.dep b/lib/compiler/doc/src/make.dep
new file mode 100644
index 0000000000..f5c097afad
--- /dev/null
+++ b/lib/compiler/doc/src/make.dep
@@ -0,0 +1,19 @@
+# ----------------------------------------------------
+# >>>> Do not edit this file <<<<
+# This file was automaticly generated by
+# /home/otp/bin/docdepend
+# ----------------------------------------------------
+
+
+# ----------------------------------------------------
+# TeX files that the DVI file depend on
+# ----------------------------------------------------
+
+book.dvi: book.tex compile.tex ref_man.tex
+
+# ----------------------------------------------------
+# Source inlined when transforming from source to LaTeX
+# ----------------------------------------------------
+
+book.tex: ref_man.xml
+
diff --git a/lib/compiler/doc/src/note.gif b/lib/compiler/doc/src/note.gif
new file mode 100644
index 0000000000..6fffe30419
--- /dev/null
+++ b/lib/compiler/doc/src/note.gif
diff --git a/lib/compiler/doc/src/notes.xml b/lib/compiler/doc/src/notes.xml
new file mode 100644
index 0000000000..7d1913d740
--- /dev/null
+++ b/lib/compiler/doc/src/notes.xml
@@ -0,0 +1,1331 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE chapter SYSTEM "chapter.dtd">
+
+<chapter>
+  <header>
+    <copyright>
+      <year>2004</year><year>2009</year>
+      <holder>Ericsson AB. All Rights Reserved.</holder>
+    </copyright>
+    <legalnotice>
+      The contents of this file are subject to the Erlang Public License,
+      Version 1.1, (the "License"); you may not use this file except in
+      compliance with the License. You should have received a copy of the
+      Erlang Public License along with this software. If not, it can be
+      retrieved online at http://www.erlang.org/.
+    
+      Software distributed under the License is distributed on an "AS IS"
+      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+      the License for the specific language governing rights and limitations
+      under the License.
+    
+    </legalnotice>
+
+    <title>Compiler Release Notes</title>
+    <prepared>otp_appnotes</prepared>
+    <docno>nil</docno>
+    <date>nil</date>
+    <rev>nil</rev>
+    <file>notes.xml</file>
+  </header>
+  <p>This document describes the changes made to the Compiler
+    application.</p>
+
+<section><title>Compiler 4.6.4</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+	    <p>The compiler's 'E' option now works with modules with
+	    types and specifications.</p>
+          <p>
+	    Own Id: OTP-8238 Aux Id: OTP-8150 </p>
+        </item>
+        <item>
+          <p>
+	    Certain uses of binary matching in a
+	    <c>begin</c>-<c>end</c> in a list comprehension could
+	    cause the compiler to crash or generate incorrect code.</p>
+          <p>
+	    Own Id: OTP-8271</p>
+        </item>
+      </list>
+    </section>
+
+
+    <section><title>Improvements and New Features</title>
+      <list>
+        <item>
+          <p>
+	    The documentation is now built with open source tools
+	    (xsltproc and fop) that exists on most platforms. One
+	    visible change is that the frames are removed.</p>
+          <p>
+	    Own Id: OTP-8201</p>
+        </item>
+        <item>
+          <p>
+	    The compiler could crash if invalid calls to is_record/2
+	    was used in (for example) a list comprehension. (Thanks
+	    to Tobias Lindahl.)</p>
+          <p>
+	    Own Id: OTP-8269</p>
+        </item>
+        <item>
+	    <p>The -on_load() directive can be used to run a function
+	    when a module is loaded. It is documented in the section
+	    about code loading in the Reference Manual.</p>
+          <p>
+	    Own Id: OTP-8295</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+<section><title>Compiler 4.6.3</title>
+
+    <section><title>Improvements and New Features</title>
+      <list>
+        <item>
+	    <p>Corrected liveness optimization to eliminate a
+	    compiler crash that could occur when compiling bit syntax
+	    construction code. (Thanks to Mikage Sawatari.)</p>
+	    <p>Calling BIFs such as <c>length/1</c> in guard context
+	    in a try/catch block could cause a compiler crash.
+	    (Thanks to Paul Fisher.)</p>
+	    <p>Using filter expressions containing <c>andalso</c> or
+	    <c>orelse</c> in a list comprehension could cause a
+	    compiler crash. (Thanks to Martin Engstr�m.)</p>
+          <p>
+	    Own Id: OTP-8054</p>
+        </item>
+        <item>
+          <p>
+	    A guard with nested 'not' operators could cause the
+	    compiler to crash. (Thanks to Tuncer Ayaz.)</p>
+          <p>
+	    Own Id: OTP-8131</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+<section><title>Compiler 4.6.2</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+          <p>
+	    The compiler would crash while compiling certain complex
+	    function bodies containing <c>receive after</c> due to a
+	    bug in the jump optimizer (a label that had only had
+	    backward references could still be removed). (Thanks to
+	    Vincent de Phily.)</p>
+          <p>
+	    Own Id: OTP-7980</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+<section><title>Compiler 4.6.1</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+          <p>
+	    Miscellaneous minor bugs fixed.</p>
+          <p>
+	    Own Id: OTP-7937</p>
+        </item>
+      </list>
+    </section>
+
+
+    <section><title>Improvements and New Features</title>
+      <list>
+        <item>
+          <p>
+	    There will be more efficient code if there is a clause
+	    that matches the empty binary and no other clauses that
+	    matches non-empty binaries.</p>
+          <p>
+	    Own Id: OTP-7924</p>
+        </item>
+        <item>
+	    <p>There is new option to allow a module to have a module
+	    name other than the filename. Do not use it unless you
+	    know what you are doing.</p>
+          <p>
+	    Own Id: OTP-7927</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+<section><title>Compiler 4.6.0.1</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+            <p>Using <c>andalso</c>/<c>orelse</c> or record access in
+            a <c>try</c>...<c>catch</c> could cause a compiler
+            crash.</p>
+            <p>Som large and complex functions could require
+            extremely long compilation times (hours or days).</p>
+          <p>
+            Own Id: OTP-7905</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+<section><title>Compiler 4.6</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+          <p>
+	    For some complex guards which used
+	    <c>andalso</c>/<c>orelse</c>, the compiler would crash.
+	    (Thanks to Hunter Morris.)</p>
+          <p>
+	    Own Id: OTP-7679</p>
+        </item>
+        <item>
+          <p>
+	    Code that (incorrectly) used the the value of nested
+	    applications of <c>setelement/3</c> in bit syntax
+	    construction could crash the compiler.</p>
+          <p>
+	    Own Id: OTP-7690</p>
+        </item>
+        <item>
+	    <p>Modules containing huge integers (consisting of
+	    several hundreds of thousands of digits or more) could be
+	    slow to compile. This problem has been corrected.</p>
+          <p>
+	    Own Id: OTP-7707 Aux Id: seq11129 </p>
+        </item>
+        <item>
+	    <p>If the generator in a list comprehension is given a
+	    non-list term, there will now be <c>function_clause</c>
+	    exception instead of a <c>case_clause</c> exception (as
+	    it was in all releases before R12B).</p>
+          <p>
+	    Own Id: OTP-7844</p>
+        </item>
+      </list>
+    </section>
+
+
+    <section><title>Improvements and New Features</title>
+      <list>
+        <item>
+          <p>
+	    The compiler could crash if the size for a binary segment
+	    in matching was a complex literal such as binary or
+	    tuple.</p>
+          <p>
+	    Own Id: OTP-7650</p>
+        </item>
+        <item>
+          <p>
+	    The compiler generates more compact and faster code for
+	    matching of complex constants (such as constant lists and
+	    tuples).</p>
+          <p>
+	    Own Id: OTP-7655</p>
+        </item>
+        <item>
+          <p>
+	    The undocumented, unsupported, and deprecated guard BIF
+	    <c>is_constant/1</c> has been removed.</p>
+          <p>
+	    *** INCOMPATIBILITY with R12B ***</p>
+          <p>
+	    Own Id: OTP-7673</p>
+        </item>
+        <item>
+	    <p>The compiler generates better code for many guard
+	    expressions, and especially for guards that use
+	    <c>andalso</c>/<c>orelse</c> or record fields.</p>
+	    <p>(In technical terms, <c>andalso</c>/<c>orelse</c> in a
+	    guard would case the creation of a stack frame and saving
+	    of all x registers that could potentially be alive after
+	    the guard and restoring all x registers before leaving
+	    the guard. For certain guards, far too many x registers
+	    were saved and subsequently restored. In this version of
+	    the compiler, no stack frame is created and no x
+	    registers are saved and restored.)</p>
+          <p>
+	    Own Id: OTP-7718</p>
+        </item>
+        <item>
+	    <p>The default size for the resulting binary created by a
+	    binary comprehension was 64Kb in R12B (it would grow if
+	    needed). This was often far too much. In this release,
+	    the default is changed to 256 bytes. Furthermore, for
+	    most binary comprehensions without filters, the exact
+	    size of the resulting binary can be calculated beforehand
+	    and the compiler now generates code that does that
+	    calculation.</p>
+          <p>
+	    Own Id: OTP-7737</p>
+        </item>
+        <item>
+	    <p>The short-circuit operators <c>andalso</c> and
+	    <c>orelse</c> no longer guarantees that their second
+	    argument is either <c>true</c> or <c>false</c>. As a
+	    consequence, <c>andalso</c>/<c>orelse</c> are now
+	    tail-recursive.</p>
+          <p>
+	    *** POTENTIAL INCOMPATIBILITY ***</p>
+          <p>
+	    Own Id: OTP-7748</p>
+        </item>
+        <item>
+	    <p>The compiler will refuse to a compile file where the
+	    module name in the file differs from the output file
+	    name.</p>
+	    <p>When compiling using <c>erlc</c>, the current working
+	    directory will no be included in the code path (unless
+	    explicitly added using "-pa .").</p>
+          <p>
+	    *** POTENTIAL INCOMPATIBILITY ***</p>
+          <p>
+	    Own Id: OTP-7793</p>
+        </item>
+        <item>
+	    <p>There will no longer be any warnings for list
+	    comprehensions without generators, as such list
+	    comprehension have turned out to be useful.</p>
+          <p>
+	    Own Id: OTP-7846</p>
+        </item>
+        <item>
+	    <p>Warnings for obsolete guard tests are now turned on.
+	    (That is, writing <c>list(L)</c> in a guard instead of
+	    <c>is_list(L)</c> will generate a warning.)</p>
+	    <p>The warnings can be turned off using the
+	    <c>nowarn_obsolete_guard</c> option.</p>
+          <p>
+	    Own Id: OTP-7850</p>
+        </item>
+        <item>
+	    <p>The copyright notices have been updated.</p>
+          <p>
+	    Own Id: OTP-7851</p>
+        </item>
+        <item>
+	    <p>If a module contains an exported function with the
+	    same name as an auto-imported BIF (such as
+	    <c>length/1</c>), any calls to the BIF must have an
+	    explicit <c>erlang:</c> prefix, or there will be a
+	    compilation error (such calls would only generate a
+	    warning in previous releases).</p>
+	    <p>(The reason for the change is to avoid breaking code
+	    in a future major release, R14 or R15, in which we plan
+	    to make calls without a module prefix always call the
+	    local function in the same module even if there is an
+	    auto-imported BIF with the same name.)</p>
+          <p>
+	    *** POTENTIAL INCOMPATIBILITY ***</p>
+          <p>
+	    Own Id: OTP-7873</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+<section><title>Compiler 4.5.5</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+	    <p>Matching on a zero-width segment in the bit syntax
+	    would crash the compiler. (Thanks to Will.)</p>
+          <p>
+	    Own Id: OTP-7591</p>
+        </item>
+      </list>
+    </section>
+
+
+    <section><title>Improvements and New Features</title>
+      <list>
+        <item>
+          <p>
+	    In bit syntax expressions which started with a binary
+	    segment, and was followed by at least two segments of
+	    variable size, too little space could be allocated for
+	    the binary, leading to memory corruption.</p>
+          <p>
+	    Own Id: OTP-7556</p>
+        </item>
+        <item>
+	    <p>In user-defined attributes, <c>Name/Arity</c> is now
+	    allowed and will be translated to <c>{Name,Arity}</c>.
+	    (An implementation of EEP-24 by Richard O'Keefe.)</p>
+	    <p>The <c>module_info/{0,1}</c> functions automatically
+	    inserted into each compiled modules are now documented in
+	    the Modules section in the Reference Manual.</p>
+          <p>
+	    Own Id: OTP-7586</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+<section><title>Compiler 4.5.4</title>
+
+    <section><title>Improvements and New Features</title>
+      <list>
+        <item>
+          <p>
+	    Certain complex bit syntax matching operations matching
+	    out binaries and having several clauses could give
+	    incorrect results (the matched out binaries were too
+	    short). (Thanks to Christian von Roques for bug report
+	    and correction.)</p>
+          <p>
+	    Own Id: OTP-7498</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+<section><title>Compiler 4.5.3</title>
+
+    <section><title>Improvements and New Features</title>
+      <list>
+        <item>
+          <p>
+	    New option <c>warn_export_all</c> to warn for a module
+	    using <c>export_all</c>. (Thanks to Richard Carlsson.)</p>
+          <p>
+	    Own Id: OTP-7392</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+<section><title>Compiler 4.5.2.1</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+          <p>
+            In rare circumstances, the length/1 BIF (and a few other
+            guard BIFs) would seem to return an incorrect value (of
+            any type).</p>
+          <p>
+            Own Id: OTP-7345 Aux Id: seq10962 </p>
+        </item>
+      </list>
+    </section>
+
+</section>
+<section><title>Compiler 4.5.2</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+	    <p>A bug in the old inliner has been fixed. Some
+	    undocumented functionality has been removed.</p>
+          <p>
+	    Own Id: OTP-7223</p>
+        </item>
+        <item>
+	    <p>Matching several binary patterns in parallel using the
+	    '=' operator is not allowed (an implementation
+	    limitation), but the compiler did not reject all such
+	    attempts (depending on the patterns, the generated code
+	    might or might not work correctly). Now the compiler
+	    rejects all binary patterns joined by '='.</p>
+          <p>
+	    Own Id: OTP-7227</p>
+        </item>
+        <item>
+	    <p>Complex combinations of record operations and binary
+	    matching could cause the compiler to crash. (Thanks to
+	    Vladimir Klebansky.)</p>
+          <p>
+	    Own Id: OTP-7233</p>
+        </item>
+        <item>
+          <p>
+	    In rare circumstances, mixing binary matching clauses
+	    with clauses matching other data types, the compiler
+	    could crash.</p>
+          <p>
+	    Own Id: OTP-7240 Aux Id: seq10916 </p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+<section><title>Compiler 4.5.1.1</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+          <p>
+	    Corrected a compiler bug that could cause a complex
+	    binary matching operation to fail when it shouldn't.
+	    (Thanks to Tomas Stejskal.)</p>
+          <p>
+	    Own Id: OTP-7188</p>
+        </item>
+        <item>
+          <p>
+	    In unusual circumstances, the environment for a fun could
+	    bind wrong values.</p>
+          <p>
+	    Own Id: OTP-7202 Aux Id: seq10887 </p>
+        </item>
+        <item>
+	    <p>Long sequences of list comprehensions without
+	    generators joined by the '++' operator would cause a code
+	    expansion explosion, which could cause the compiler to
+	    run out of memory. To resolve this problem, in
+	    '<c>[...||...]++Expr</c>', <c>Expr</c> is now evaluated
+	    before the list comprehension. This change <em>is</em>
+	    backwards compatible (see the following note about
+	    evaluation order if you have doubts).</p>
+	    <p>Note about evaluation order: The Reference manual says
+	    that subexpressions are evaluated <em>in any order</em>
+	    before the expression itself. Therefore, in an expression
+	    such as '<c>LeftExpr++RightExpr</c>', you should not
+	    depend on <c>LeftExpr</c> being evaluated before
+	    <c>RightExpr</c> or vice versa. The evaluation order is
+	    only important if the expressions contains and/or depends
+	    on operations with side-effects, such as message passing
+	    or <c>ets</c> operations.</p>
+          <p>
+	    Own Id: OTP-7206</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+
+<section><title>Compiler 4.5.1</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+          <p>
+	    A match expression inside a function call could cause a
+	    false "a term is constructed but never used" warning.</p>
+          <p>
+	    Own Id: OTP-7018 Aux Id: seq10824 </p>
+        </item>
+        <item>
+	    <p>The compiler could crash if a binary tail was matched
+	    out, and then used in a binary append operation. (Thanks
+	    to Oleg Avdeev.)</p>
+	    <p>Similarly, the compiler could crash if a binary tail
+	    was matched out, and then used (incorrectly) in binary
+	    construction in an integer field. (Thanks to Fredrik
+	    Svahn.) Or was incorrectly used in a float field. Or was
+	    used in a binary field with a given length. (Thanks to
+	    Chih - Wei Yu.) </p>
+          <p>
+	    Own Id: OTP-7022</p>
+        </item>
+        <item>
+          <p>
+	    Matching an empty binary in a record and then using the
+	    same record again could cause a compiler crash. (Thanks
+	    to Fredrik Thulin.)</p>
+          <p>
+	    Own Id: OTP-7029</p>
+        </item>
+        <item>
+	    <p>In rare circumstances, constants containing floating
+	    points and integers could be confused. Example:</p>
+	    <p><c>f(a) -> [1]; f(b) -> [1.0].</c></p>
+	    <p>Both <c>f(a)</c> and <c>f(b)</c> would return
+	    <c>[1]</c>.</p>
+          <p>
+	    Own Id: OTP-7073</p>
+        </item>
+        <item>
+	    <p>Some bit syntax code such as</p>
+	    <p><c>matching d(_,&lt;$lt;$gt;$gt;) -> one; d(0,&lt;$lt;D$gt;$gt;)
+	    ->two.</c></p>
+	    <p>could crash the compiler. (Thanks to Simon
+	    Cornish.)</p>
+          <p>
+	    Own Id: OTP-7094</p>
+        </item>
+        <item>
+          <p>
+	    In unusual circumstances, a call to a fun could fail due
+	    to an unsafe optimization. (Thanks to Simon Cornish.)</p>
+          <p>
+	    Own Id: OTP-7102</p>
+        </item>
+        <item>
+          <p>
+	    Bit syntax matching with a guard containing two or more
+	    uses of andalso/orelse could cause the compiler to crash.
+	    (Thanks to Mateusz Berezecki.)</p>
+          <p>
+	    Own Id: OTP-7113</p>
+        </item>
+        <item>
+          <p>
+	    This was only a problem if you generated or wrote your
+	    own Core Erlang code: The Core Erlang optimizer code
+	    could move nested calls such as
+	    <c>erlang:'$lt;'(erlang:length(L), 2)</c> as case expression
+	    into a guard, which would change the semantics. (Thanks
+	    to Robert Virding.)</p>
+          <p>
+	    Own Id: OTP-7117</p>
+        </item>
+      </list>
+    </section>
+
+
+    <section><title>Improvements and New Features</title>
+      <list>
+        <item>
+          <p>
+	    The compiler could generate suboptimal code for record
+	    updates if the record update code consisted of multiple
+	    source code lines.</p>
+          <p>
+	    Own Id: OTP-7101</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+<section><title>Compiler 4.5</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+	    <p>The compiler used to allow that a binary field without
+	    size could be used in other positions than at the end in
+	    bit syntax pattern. For instance,
+	    <c><![CDATA[<<B/binary,EmptyBinary/binary>> = Bin]]></c>
+	    used to compile, but now the compilation will fail with
+	    an an error message.</p>
+	    <p>Also, it is now longer permitted to give a literal
+	    string in a binary pattern a type or a size; for
+	    instance, <c><![CDATA[<<"abc"/binary>> = Bin]]></c> will
+	    no longer compile. (In previous releases, there would
+	    always be a <c>badmatch</c> exception at run-time.)</p>
+          <p>
+	    Own Id: OTP-6885</p>
+        </item>
+      </list>
+    </section>
+
+
+    <section><title>Improvements and New Features</title>
+      <list>
+        <item>
+          <p>
+	    Bitstrings (bit-level) binaries and binary comprehensions
+	    are now part of the language. See the Reference Manual.</p>
+          <p>
+	    Own Id: OTP-6558</p>
+        </item>
+        <item>
+          <p>
+	    The '<c>compressed</c>' option for the compiler has been
+	    documented.</p>
+          <p>
+	    Own Id: OTP-6801</p>
+        </item>
+        <item>
+	    <p>If the value of a list comprehension is not used, such
+	    as in '<c>[do_something(X) || X &lt;- List], ok</c>', a
+	    result list will no longer be built. For more details,
+	    see the Efficiency Guide.</p>
+	    <p>If the value of an expression is not used, and the
+	    expression has no side effects except for possibly
+	    throwing an exception, a warning will be generated.
+	    Examples: '<c>self(),ok</c>' and
+	    '<c>{error,Reason},ok</c>'.</p>
+          <p>
+	    Own Id: OTP-6824</p>
+        </item>
+        <item>
+          <p>
+	    Three new functions have been added to the <c>compile</c>
+	    module: <c>noenv_file/2</c>, <c>noenv_forms/2</c>, and
+	    <c>noenv_output_generated/1</c>.</p>
+          <p>
+	    Own Id: OTP-6829</p>
+        </item>
+        <item>
+	    <p>Many bit syntax operations, both construction and
+	    matching, are faster. For further information, see the
+	    Efficiency Guide.</p>
+          <p>
+	    Own Id: OTP-6838</p>
+        </item>
+        <item>
+	    <p>Literal lists, tuples, and binaries are no longer
+	    constructed at run-time as they used to be, but are
+	    stored in a per-module constant pool. Literals that are
+	    used more than once are stored only once.</p>
+	    <p>This is not a change to the language, only in the
+	    details of its implementation. Therefore, the
+	    implications of this change is described in the
+	    Efficiency Guide.</p>
+	    <p>Example 1: In the expression <c>element(BitNum-1,
+	    {1,2,4,8,16,32,64,128})</c>, the tuple used to be
+	    constructed every time the expression was executed, which
+	    could be detrimental to performance in two ways if the
+	    expression was executed in a loop: the time to build the
+	    tuple itself and the time spent in garbage collections
+	    because the heap filled up with garbage faster.</p>
+	    <p>Example 2: Literal strings, such as <c>"abc"</c>, used
+	    to be stored in the compiled code compactly as a byte
+	    string and expanded to a list at run-time. Now all
+	    strings will be stored expanded to lists (such as
+	    <c>[$a,$b,$c]</c>) in the constant pool. That means that
+	    the string will be faster to use at run-time, but that it
+	    will require more space even when not used. If space is
+	    an issue, you might want to use binary literals (that is,
+	    <c>&lt;&lt;"abc"&lt;&lt;</c>) instead of string literals for
+	    infrequently used long strings (such as error
+	    messages).</p>
+          <p>
+	    Own Id: OTP-6850</p>
+        </item>
+        <item>
+          <p>
+	    Recursive calls now usually consume less stack than in
+	    R11B. See the Efficiency Guide.</p>
+          <p>
+	    Own Id: OTP-6862 Aux Id: seq10746 </p>
+        </item>
+        <item>
+	    <p>Two new guard BIFs have been introduced as a
+	    recommended replacement for <c>size/1</c>. (The
+	    <c>size/1</c> BIF will be removed no earlier than in
+	    R14B.) The BIFs are <c>tuple_size/1</c> to calculate the
+	    size of a tuple and <c>byte_size/1</c> to calculate the
+	    number of bytes needed for the contents of the binary or
+	    bitstring (rounded up to the nearest number of bytes if
+	    necessary).</p>
+	    <p>There is also a new <c>bit_size/1</c> BIF that returns
+	    the exact number of bits that a binary or bitstring
+	    contains.</p>
+          <p>
+	    Own Id: OTP-6902</p>
+        </item>
+        <item>
+          <p>
+	    The two internal functions <c>erl_bifs:is_bif/3</c> and
+	    <c>erl_bifs:is_guard/3</c> have been removed. They were
+	    unsupported, undocumented, and unmaintained.</p>
+          <p>
+	    Own Id: OTP-6966</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+  <section>
+    <title>Compiler 4.4.5</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>The compiler would crash if you tried to combine to
+            non-list literals with '<c><![CDATA[++]]></c>' (for instance,
+            <c><![CDATA[an_atom++"string"]]></c>).</p>
+          <p>Own Id: OTP-6630 Aux Id: seq10635 </p>
+        </item>
+      </list>
+    </section>
+
+    <section>
+      <title>Improvements and New Features</title>
+      <list type="bulleted">
+        <item>
+          <p>Minor Makefile changes.</p>
+          <p>Own Id: OTP-6689</p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.4.4</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>Incorrect code could be generated for bit syntax matching
+            if the old inliner was used with aggressive settings.</p>
+          <p>Own Id: OTP-6461</p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.4.3</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>The R10B compiler could generate unsafe
+            <c><![CDATA[bs_save/bs_restore]]></c> instructions that could cause
+            memory corruption. (The R11B compiler does not have that
+            problem.) The erlang emulator will now refuse to load
+            R10B-compiled modules that contain such unsafe
+            <c><![CDATA[bs_save/bs_restore]]></c> instructions. In addition, the
+            beam_validator module in the compiler will also reject
+            such instructions (in case it is used to validate R10B
+            code). (Thanks to Matthew Reilly.)</p>
+          <p>Own Id: OTP-6386</p>
+        </item>
+      </list>
+    </section>
+
+    <section>
+      <title>Improvements and New Features</title>
+      <list type="bulleted">
+        <item>
+          <p>Directives for parse transforms that have been run are
+            now removed from the abstract code stored when the
+            debug_info option is given, to prevent the parse
+            transforms to be run again.</p>
+          <p>Own Id: OTP-5344</p>
+        </item>
+        <item>
+          <p>Minor improvements in code generation for some guards
+            expression involving boolean expressions.</p>
+          <p>Own Id: OTP-6347</p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.4.2.1</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>The compiler could generate incorrect code for bit syntax
+            matching consisting of several clauses.</p>
+          <p>Own Id: OTP-6392 Aux Id: seq10539 </p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.4.2</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>Defining a fun itself containing a fun in an
+            <c><![CDATA[after]]></c> block of a <c><![CDATA[try]]></c> would cause the
+            compiler to crash or generate incorrect code. (Thanks to
+            Tim Rath.)</p>
+          <p>Shorter compilation times for modules containing with
+            an extreme number of functions (10000 functions or more).</p>
+          <p>(The compiled could generate deprecated instructions
+            for certain bit syntax matching operations.)</p>
+          <p>Own Id: OTP-6212 Aux Id: seq10446 </p>
+        </item>
+        <item>
+          <p>Fixed several bugs that would cause warnings to be shown
+            without file name and line number.</p>
+          <p>Own Id: OTP-6260 Aux Id: seq10461 </p>
+        </item>
+      </list>
+    </section>
+
+    <section>
+      <title>Improvements and New Features</title>
+      <list type="bulleted">
+        <item>
+          <p>The <c><![CDATA[strict_record_tests]]></c> option is now default;
+            that is, reading a field from a record using the
+            <c><![CDATA[Record#record_tag.field]]></c> syntax will fail if
+            <c><![CDATA[Record]]></c> is not a record of the correct type.</p>
+          <p>If necessary, the record tests can be turned off by
+            giving the <c><![CDATA[no_strict_record_tests]]></c> option. To avoid
+            editing Makefiles, the environment variable
+            <c><![CDATA[ERL_COMPILER_OPTIONS]]></c> can be set to
+            "<c><![CDATA[no_strict_record_tests]]></c>".</p>
+          <p>The <c><![CDATA[no_strict_record_tests]]></c> option will probably
+            be removed in the R12B release.</p>
+          <p>*** POTENTIAL INCOMPATIBILITY ***</p>
+          <p>Own Id: OTP-6294</p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.4.1</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>The compiler used to crash if a module contained code
+            similar to '<c><![CDATA[fun(1=0) -> ok end]]></c>'. (Thanks to
+            Richard Carlsson.)</p>
+          <p>The compiler would spend really long time compiling
+            bit syntax expressions such as
+            '<c><![CDATA[<<1:(50*1024*1024)>>]]></c>' and produce a huge .beam
+            file. Corrected.</p>
+          <p>The compiler would compile list comprehensions with
+            many generators really, really slow. (Thanks to Thomas
+            Raes.)</p>
+          <p>Module attributes would be stored in reverse order
+            compared to the order in the source code. (Thus,
+            <c><![CDATA[M:module_info(attributes)]]></c> would also return the
+            attributes in reversed order.)</p>
+          <p>Defining a fun in an <c><![CDATA[after]]></c> block of a
+            <c><![CDATA[try]]></c> would cause the compiler to crash or generate
+            incorrect code. (Thanks to Martin Bjorklund.)</p>
+          <p>The combination of binary pattern and a guard with
+            andalso/orelse could cause the compiler to crash.</p>
+          <p>Own Id: OTP-6121 Aux Id: seq10400 </p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.4</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>When a <c><![CDATA[.hrl]]></c> file is included using
+            <c><![CDATA[-include_lib]]></c>, the include path is temporarily
+            updated to include the directory the <c><![CDATA[.hrl]]></c> file was
+            found in, which will allow that <c><![CDATA[.hrl]]></c> file to itself
+            include files from the same directory using
+            <c><![CDATA[-include]]></c>. (Thanks to Richard Carlsson.)</p>
+          <p>Own Id: OTP-5944</p>
+        </item>
+      </list>
+    </section>
+
+    <section>
+      <title>Improvements and New Features</title>
+      <list type="bulleted">
+        <item>
+          <p>The <c><![CDATA[andalso]]></c> and <c><![CDATA[orelse]]></c> operators are
+            now allowed to be used in guards. That also applies to
+            match specifications.</p>
+          <p>Own Id: OTP-5894 Aux Id: OTP-5149 </p>
+        </item>
+        <item>
+          <p>When given the new option
+            <c><![CDATA[strict_record_tests]]></c>, the compiler will generate
+            code that verifies the record type for
+            <c><![CDATA[R#record.field]]></c> operations in guards. Code that
+            verifies record types in bodies has already been
+            generated since R10B, but in this release there will be a
+            <c><![CDATA[{badrecord,RecordTag}]]></c> instead of a
+            <c><![CDATA[badmatch]]></c> if the record verification test fails.
+            See <c><![CDATA[compile(3)]]></c> for more information.</p>
+          <p>The Erlang shell always applies strict record tests.</p>
+          <p>Own Id: OTP-5915 Aux Id: OTP-5714 </p>
+        </item>
+        <item>
+          <p>The BIF <c><![CDATA[is_record/3]]></c> can now be used in guards.
+            Also, <c><![CDATA[is_record/3]]></c> can now be called without an
+            <c><![CDATA[erlang:]]></c> module prefix for consistency with the other
+            <c><![CDATA[is_*]]></c> functions.</p>
+          <p>Own Id: OTP-5916</p>
+        </item>
+        <item>
+          <p>The compiler options <c><![CDATA[ignore_try]]></c> and
+            <c><![CDATA[ignore_cond]]></c>, which allowed code that used
+            unquoted <c><![CDATA[try]]></c> or <c><![CDATA[cond]]></c> as atoms or record
+            tags, has been removed. Old code that depended on the
+            options need to be revised to have occurrences of
+            <c><![CDATA[try]]></c> or <c><![CDATA[cond]]></c> as atom or record tags
+            single-quoted. (Note: Although <c><![CDATA[cond]]></c> is a reserved
+            keyword, there is no <c><![CDATA[cond]]></c> statement. It might be
+            introduced in a future release.)</p>
+          <p>*** POTENTIAL INCOMPATIBILITY ***</p>
+          <p>Own Id: OTP-6058</p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.3.12</title>
+
+    <section>
+      <title>Improvements and New Features</title>
+      <list type="bulleted">
+        <item>
+          <p>The following code would crash the compiler: <c><![CDATA[case T of #r{s = ""} -> T #r{s = "x"} end]]></c>. (Thanks to
+            Richard Carlsson.)</p>
+          <p>The compiler could crash if binaries were constructed
+            in certain guards involving boolean operators (including
+            semicolon). (Thanks to Torbjorn Tornkvist.)</p>
+          <p>Own Id: OTP-5872</p>
+        </item>
+        <item>
+          <p>The compiler will now warn that the
+            <c><![CDATA[megaco:format_versions/1]]></c> function is deprecated.</p>
+          <p>Own Id: OTP-5976</p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.3.11</title>
+
+    <section>
+      <title>Improvements and New Features</title>
+      <list type="bulleted">
+        <item>
+          <p>The compiler would assume that some patterns with
+            aliases ('=') would not match if they were split into
+            several lines. (Thanks to Peter Nagy/Mats Cronqvist.)</p>
+          <p>Minor cleanups to eliminate Dialyzer warnings.</p>
+          <p>Own Id: OTP-5791 Aux Id: seq10141 </p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.3.10</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>When given the new option
+            <c><![CDATA[strict_record_tests]]></c>, the compiler will generate
+            code that verifies the record type for
+            <c><![CDATA[R#record.field]]></c> operations (in body context only,
+            not in guards). See the documentation for the
+            <c><![CDATA[compile]]></c> module for more information.</p>
+          <p>The beam validator pass of the compiler could crash
+            given in rare circumstances when given certain
+            combinations of catches and record operations. (Thanks to
+            Mats Cronqvist.)</p>
+          <p>Attributes containing binaries (such as -a(&lt;&lt;1,2,3&gt;&gt;))
+            would crash the compiler. (Thanks to Roger Price.)</p>
+          <p>Multiple behaviours in the same module will no longer
+            generate a warning, unless one or more callbacks for the
+            behaviours overlap. For instance, using both the
+            <c><![CDATA[application]]></c> and <c><![CDATA[supervisor]]></c> behaviours
+            in the same module will NOT generate any warning, but
+            using <c><![CDATA[gen_server]]></c> and <c><![CDATA[gen_fsm]]></c> will.</p>
+          <p>Own Id: OTP-5714 Aux Id: seq10073 </p>
+        </item>
+        <item>
+          <p>The pre-processor used to complain that the macro
+            definition <c><![CDATA[-define(S(S), ??S).]]></c> was circular,
+            which it isn't. (Thanks to Richard Carlsson.)</p>
+          <p>Own Id: OTP-5777</p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.3.9</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>Updating at least two fields of a record with a literal
+            string could cause the compiler to generate dangerous
+            code that could cause a crash at run-time (e.g.
+            <c><![CDATA[R#r{a="abc",b=1}]]></c>). (Thanks to Mikael Karlsson.)</p>
+          <p>Unecessary tests (such as a 'case' with two case
+            branches that were identical) could cause the compiler to
+            crash. (Thanks to Fredrik Thulin.)</p>
+          <p>The validation pass of the compiler could generate an
+            error for correct code when floating point operations
+            were used in try/catch statements.</p>
+          <p>In bit syntax construction, any field following a
+            binary field would always be marked as "aligned" (which
+            may or may not be correct). That would cause the hipe
+            native compiler to generate incorrect code if the field
+            was in fact unaligned. (Thanks to Per Gustafsson.)</p>
+          <p>Some complex guard expressions (such as <c><![CDATA[A#a.b==""; A#a.b==undefined]]></c>) would crash the compiler. (Thanks
+            to Sean Hinde.)</p>
+          <p>Compilation speed has been increased for modules with
+            many functions and/or atoms (such as modules generated by
+            the Asn1 application or other code generators).</p>
+          <p>Own Id: OTP-5632 Aux Id: seq10057 </p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.3.8</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>In some circumstances, having two try/catch constructs
+            following each in a function body, would cause an
+            internal error to be generated (when in fact the
+            generated code was correct). (Thanks to Fredrik Thulin.)</p>
+          <p>Incorrect calls such as <c><![CDATA[M:42()]]></c> would crash the
+            compiler. The compiler now generates a warning. (Thanks
+            to Ulf Wiger.)</p>
+          <p>Own Id: OTP-5553</p>
+        </item>
+      </list>
+    </section>
+
+    <section>
+      <title>Improvements and New Features</title>
+      <list type="bulleted">
+        <item>
+          <p>The new <c><![CDATA[fun M:F/A]]></c> construct creates a fun that
+            refers to the latest version of <c><![CDATA[M:F/A]]></c>. This syntax is
+            meant to replace tuple funs <c><![CDATA[{M,F}]]></c> which have many
+            problems.</p>
+          <p>The new type test <c><![CDATA[is_function(Fun, A)]]></c> (which may be
+            used in guards) test whether <c><![CDATA[Fun]]></c> is a fun that can be
+            applied with <c><![CDATA[A]]></c> arguments. (Currently, <c><![CDATA[Fun]]></c> can
+            also be a tuple fun.)</p>
+          <p>Own Id: OTP-5584</p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.3.7</title>
+
+    <section>
+      <title>Improvements and New Features</title>
+      <list type="bulleted">
+        <item>
+          <p>Further improvements of encrypted debug info: New option
+            <c><![CDATA[encrypt_debug_info]]></c> for compiler.</p>
+          <p>Own Id: OTP-5541 Aux Id: seq9837 </p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.3.6</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>Fixed a bug in the validator of the generated code
+            (beam_validator) which caused an internal compiler error
+            even though the generated code was indeed correct.</p>
+          <p>Own Id: OTP-5481 Aux Id: seq9798 </p>
+        </item>
+      </list>
+    </section>
+
+    <section>
+      <title>Improvements and New Features</title>
+      <list type="bulleted">
+        <item>
+          <p>It is now possible to encrypt the debug information in
+            Beam files, to help keep the source code secret. See the
+            documentation for <c><![CDATA[compile]]></c> on how to provide the key
+            for encrypting, and the documentation for <c><![CDATA[beam_lib]]></c>
+            on how to provide the key for decryption so that tools such
+            as the Debugger, Xref, or Cover can be used.</p>
+          <p>The <c><![CDATA[beam_lib:chunks/2]]></c> functions now accepts an
+            additional chunk type <c><![CDATA[compile_info]]></c> to retrieve
+            the compilation information directly as a term. (Thanks
+            to Tobias Lindahl.)</p>
+          <p>Own Id: OTP-5460 Aux Id: seq9787 </p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.3.5</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>Complex functions could cause the internal validator in
+            the compiler to generate an internal error even though
+            the generated code was correct.</p>
+          <p>Own Id: OTP-5436 Aux Id: seq9781 </p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.3.4</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>In rare circumstances, incorrect code for record or
+            tuple access could be generated. The incorrect code would
+            either trigger an internal error in the compiler or cause
+            an exception at run time. (Thanks to Martin Bjorklund.)</p>
+          <p>Corrected a bug in in bit syntax matching where
+            clauses could match in the wrong order. (Thanks to Ulf
+            Wiger.)</p>
+          <p>Own Id: OTP-5404 Aux Id: seq9767 </p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.3.3</title>
+
+    <section>
+      <title>Improvements and New Features</title>
+      <list type="bulleted">
+        <item>
+          <p>Given bit syntax construction in certain complex
+            contexts involving a catch, the compiler would either
+            crash or terminate due to failure in an internal
+            consistency check. (Thanks to Fredrik Thulin.)</p>
+          <p>Matches such as
+            <c><![CDATA[<<103133:64/float>> = <<103133:64/float>>]]></c>
+            used to fail. Now they succeed.</p>
+          <p>Shadowing of variables in bit syntax matches in fun heads
+            such as in
+            <c><![CDATA[L = 8, F = fun(<<L:L,B:L>>) -> B end]]></c> was
+            handled incorrectly by the compiler. The fun used to be
+            compiled as if it was written
+            '<c><![CDATA[>fun(<<8:8,B:8>>)]]></c>, while it should be
+            compiled in the same way as <c><![CDATA[fun(<<L:8,B:L>>)]]></c>.</p>
+          <p>A bug in the validation pass has been corrected. It
+            sometimes occurred when the compiler optimized by reusing
+            code for causing an exception when the reused code was
+            called from within catch or try-catch statements. Then the
+            validator refused to approve the code and complained about
+            <c><![CDATA[fun(<<L:L,B:L>>) -> B end]]></c> was handled
+            incorrectly by the in the same way as
+            <c><![CDATA[fun(<<L:8,B:L>>)]]></c>.</p>
+          <p>A bug in the unknown_catch_try_state.</p>
+          <p>Corrected a bug in the optimizer that would cause
+            the compiler to crash. (Thanks to Peter-Henry Mander.)</p>
+          <p>There are now warnings generated if a bit syntax
+            construction will fail at run-time because of a type
+            mismatch (e.g. <c><![CDATA[<<an_atom:8>>]]></c>).</p>
+          <p>Own Id: OTP-5342 Aux Id: OTP-5118, OTP-5270, OTP-5323 </p>
+        </item>
+        <item>
+          <p>Binary pattern matching such as
+            <c><![CDATA[t(<<A:8>> = <<A:8>)]]></c> used to silently
+            fail at runtime (i.e. never match). The compiler now
+            generates an error for any such patterns.</p>
+          <p>Own Id: OTP-5371</p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.3.2</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>In rare cases, the code compiler code generate code
+            for a tuple match that could crash the emulator if passed
+            a term that was not a tuple.</p>
+          <p>If a bit syntax construction failed within a catch,
+            previously assigned variables could get the wrong value.</p>
+          <p>The compiler now runs a validation pass on the
+            generated code and aborts before writing a Beam file if
+            any suspect code is found. In particular, the validation
+            pass checks for incorrect code that may cause emulator
+            crashes or other strange symptoms in the emulator.</p>
+          <p>Some corrections to the unsupported feature
+            parameterized modules by Richard Carlsson (HiPE).</p>
+          <p>Own Id: OTP-5247 Aux Id: OTP-5235 </p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.3.1</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>Corrected the release note regarding <c><![CDATA[try/catch]]></c> below.
+            <c><![CDATA[try/catch]]></c> DOES work in the initial R10B release.</p>
+          <p>A few minor issues code generation issues were corrected.
+            Although the generated code was correct, it was slightly
+            slower and larger than it needed to be.</p>
+          <p>A debug printout (that could be seen in rare
+            circumstances) has been removed.</p>
+          <p><c><![CDATA[not record_test(not_a_tuple, RecordTag)]]></c> and
+            similar expressions in a guard would fail.</p>
+          <p>New options <c><![CDATA[basic_validation]]></c> and
+            <c><![CDATA[strong_validation]]></c> to do a quick check of the code
+            of a module.</p>
+          <p>The <c><![CDATA[inline]]></c> option was not recognized if it
+            appeared in a <c><![CDATA[-compile()]]></c> directive inside the
+            module.</p>
+          <p>Corrected some bugs in the undocumented feature
+            "parameterized modules".</p>
+          <p>Own Id: OTP-5198</p>
+        </item>
+        <item>
+          <p>When the undocumented feature "parameterized modules" was
+            used, the <c><![CDATA[?MODULE]]></c> macro did not work correctly.</p>
+          <p>Own Id: OTP-5224</p>
+        </item>
+      </list>
+    </section>
+  </section>
+</chapter>
+
diff --git a/lib/compiler/doc/src/notes_history.xml b/lib/compiler/doc/src/notes_history.xml
new file mode 100644
index 0000000000..db0dc2f683
--- /dev/null
+++ b/lib/compiler/doc/src/notes_history.xml
@@ -0,0 +1,200 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE chapter SYSTEM "chapter.dtd">
+
+<chapter>
+  <header>
+    <copyright>
+      <year>2006</year><year>2009</year>
+      <holder>Ericsson AB. All Rights Reserved.</holder>
+    </copyright>
+    <legalnotice>
+      The contents of this file are subject to the Erlang Public License,
+      Version 1.1, (the "License"); you may not use this file except in
+      compliance with the License. You should have received a copy of the
+      Erlang Public License along with this software. If not, it can be
+      retrieved online at http://www.erlang.org/.
+    
+      Software distributed under the License is distributed on an "AS IS"
+      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+      the License for the specific language governing rights and limitations
+      under the License.
+    
+    </legalnotice>
+
+    <title>Compiler Release Notes History</title>
+    <prepared>otp_appnotes</prepared>
+    <docno>nil</docno>
+    <date>nil</date>
+    <rev>nil</rev>
+  </header>
+
+  <section>
+    <title>Compiler 4.3</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>The semantics for boolean operators in guards have
+            been changed to be more consistent.</p>
+          <p>All boolean operators will fail if given non-boolean
+            arguments; '<c><![CDATA[true or garbage]]></c>' used to succeed but
+            will now fail. Also, failure in the evaluation of
+            the operands will also cause the guard to fail;
+            '<c><![CDATA[true or element(1, [])]]></c>' used to succeed but will
+            now fail.</p>
+          <p>Semicolon will behave as it used to. If a failure as
+            described above occurs, evaluation will continue with
+            the right operand of the semicolon.</p>
+          <p>*** POTENTIAL INCOMPATIBILITY ***</p>
+          <p>Own Id: OTP-4623</p>
+        </item>
+        <item>
+          <p><c><![CDATA[-compile(...)]]></c> attributes inside an Erlang module
+            can now contain compiler options that control warnings
+            (such as <c><![CDATA[warn_unused_vars]]></c>). They used to be ignored.</p>
+          <p>Own Id: OTP-4911</p>
+        </item>
+        <item>
+          <p>When a record was updated, and the record given as an
+            expression (such as function call), the record could be
+            evaluated more than once.</p>
+          <p>Own Id: OTP-4933</p>
+        </item>
+        <item>
+          <p>Compilation of modules with long strings could be
+            extremely slow.</p>
+          <p>Own Id: OTP-4960 Aux Id: seq8310 </p>
+        </item>
+        <item>
+          <p>In bit syntax matching with clauses having guards,
+            sometimes the following clauses would never match if a
+            guard was evaluated (and failed).</p>
+          <p>Own Id: OTP-4961 Aux Id: seq8338, OTP-4891 </p>
+        </item>
+        <item>
+          <p>Using multiple matching ('=') in the pattern for a
+            generator in list comprehension would cause an internal
+            compiler error.</p>
+          <p>Example:</p>
+          <code type="none"><![CDATA[
+[3 || {3=4} <- []].
+          ]]></code>
+          <p>Own Id: OTP-5076 Aux Id: OTP-5092 </p>
+        </item>
+        <item>
+          <p>List and string literals, and integer and character
+            literals were not equivalent in matching as they should
+            be. For instance, <c><![CDATA[f("a"=[$a])]]></c> would never match.</p>
+          <p>Own Id: OTP-5092 Aux Id: OTP-5076 </p>
+        </item>
+      </list>
+    </section>
+
+    <section>
+      <title>Improvements and New Features</title>
+      <list type="bulleted">
+        <item>
+          <p>The compiler used to warn for definition of functions
+            having the same name as an auto-imported BIF (such as
+            <c><![CDATA[size/1]]></c>). In the R10B release, such warnings will
+            only be emitted if the function is NOT exported (because it
+            will be impossible to call it). Instead, there will be a
+            warning for any local call (call without module prefix)
+            to any (exported) function in the same module that is
+            also the name of an auto-imported BIF. To avoid the
+            warning, insert a module prefix (either <c><![CDATA[erlang]]></c> to
+            call the BIF, or the name of the module to call function in
+            the module).</p>
+          <p>Own Id: OTP-4909</p>
+        </item>
+        <item>
+          <p>The unary '+' operator has been changed to throw an
+            <c><![CDATA[badarith]]></c> exception if its argument is not numeric (or
+            fail in a guard). It used its argument unchanged whatever
+            the type. Given the new meaning, unary '+' can now be
+            used to test whether a term is numeric.</p>
+          <p>*** POTENTIAL INCOMPATIBILITY ***</p>
+          <p>Own Id: OTP-4928</p>
+        </item>
+        <item>
+          <p>The compiler now warns for more types of suspect code,
+            such as expressions that will fail at run-time (such as
+            <c><![CDATA[atom-42]]></c>), guards that are always false, or
+            patterns that cannot match.</p>
+          <p>Own Id: OTP-5098 Aux Id: seq8965, OTP-2456 </p>
+        </item>
+        <item>
+          <p>The long-awaited <c><![CDATA[try]]></c>...<c><![CDATA[catch]]></c> construction
+            is included in this release. See the reference manual
+            for how to use it.</p>
+          <p>Own Id: OTP-5150</p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.2.3</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>The compiler could generate incorrect code for receive
+            clauses did not use the message in any way, for instance
+            if a guard would ignore message depending on some
+            condition not based on the contents of the message (e.g.
+            a state variable in the "loop data").</p>
+          <p>Own Id: OTP-5050</p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.2.2</title>
+
+    <section>
+      <title>Fixed Bugs and Malfunctions</title>
+      <list type="bulleted">
+        <item>
+          <p>Compilation of modules with long strings could be
+            extremely slow.</p>
+          <p>Own Id: OTP-4960 Aux Id: seq8310 </p>
+        </item>
+        <item>
+          <p>In bit syntax matching with clauses having guards,
+            sometimes the following clauses would never match if a
+            guard was evaluated (and failed).</p>
+          <p>Own Id: OTP-4961 Aux Id: seq8338, OTP-4891 </p>
+        </item>
+        <item>
+          <p>In <c><![CDATA[(Expr)#rec{a=A,b=B}]]></c>, <c><![CDATA[Expr]]></c> would be
+            evaluated more than once.</p>
+          <p>Own Id: OTP-4962 Aux Id: seq8292 </p>
+        </item>
+      </list>
+    </section>
+  </section>
+
+  <section>
+    <title>Compiler 4.2.1</title>
+
+    <section>
+      <title>Improvements and New Features</title>
+      <list type="bulleted">
+        <item>
+          <p>In rare circumstances, the compiler could optimize away
+            test that would verify that a tuple or record argument
+            indeed was of the correct type (resulting in an emulator
+            crash if the argument was not of the correct type/size).
+            Wrong code could also be generated for floating point
+            expressions.</p>
+          <p>Own Id: OTP-4790</p>
+        </item>
+      </list>
+    </section>
+  </section>
+</chapter>
+
diff --git a/lib/compiler/doc/src/part_notes.xml b/lib/compiler/doc/src/part_notes.xml
new file mode 100644
index 0000000000..e730e3f7e2
--- /dev/null
+++ b/lib/compiler/doc/src/part_notes.xml
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE part SYSTEM "part.dtd">
+
+<part xmlns:xi="http://www.w3.org/2001/XInclude">
+  <header>
+    <copyright>
+      <year>2004</year><year>2009</year>
+      <holder>Ericsson AB. All Rights Reserved.</holder>
+    </copyright>
+    <legalnotice>
+      The contents of this file are subject to the Erlang Public License,
+      Version 1.1, (the "License"); you may not use this file except in
+      compliance with the License. You should have received a copy of the
+      Erlang Public License along with this software. If not, it can be
+      retrieved online at http://www.erlang.org/.
+    
+      Software distributed under the License is distributed on an "AS IS"
+      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+      the License for the specific language governing rights and limitations
+      under the License.
+    
+    </legalnotice>
+
+    <title>Compiler Release Notes</title>
+    <prepared></prepared>
+    <docno></docno>
+    <date>2004-09-07</date>
+    <rev>1.0</rev>
+  </header>
+  <description>
+    <p>The <em>Compiler</em> application compiles Erlang
+      code to byte-code. The highly compact byte-code is executed by
+      the Erlang emulator.</p>
+    <p>For information about older versions, see
+      <url href="part_notes_history_frame.html">Release Notes History</url>.</p>
+  </description>
+  <xi:include href="notes.xml"/>
+</part>
+
diff --git a/lib/compiler/doc/src/part_notes_history.xml b/lib/compiler/doc/src/part_notes_history.xml
new file mode 100644
index 0000000000..cd17c4285e
--- /dev/null
+++ b/lib/compiler/doc/src/part_notes_history.xml
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE part SYSTEM "part.dtd">
+
+<part>
+  <header>
+    <copyright>
+      <year>2006</year>
+      <year>2007</year>
+      <holder>Ericsson AB, All Rights Reserved</holder>
+    </copyright>
+    <legalnotice>
+  The contents of this file are subject to the Erlang Public License,
+  Version 1.1, (the "License"); you may not use this file except in
+  compliance with the License. You should have received a copy of the
+  Erlang Public License along with this software. If not, it can be
+  retrieved online at http://www.erlang.org/.
+
+  Software distributed under the License is distributed on an "AS IS"
+  basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+  the License for the specific language governing rights and limitations
+  under the License.
+
+  The Initial Developer of the Original Code is Ericsson AB.
+    </legalnotice>
+
+    <title>Compiler Release Notes History</title>
+    <prepared></prepared>
+    <docno></docno>
+    <date></date>
+    <rev></rev>
+  </header>
+  <description>
+    <p>The <em>Compiler</em> application compiles Erlang
+      code to byte-code. The highly compact byte-code is executed by
+      the Erlang emulator.</p>
+  </description>
+  <include file="notes_history"></include>
+</part>
+
diff --git a/lib/compiler/doc/src/ref_man.xml b/lib/compiler/doc/src/ref_man.xml
new file mode 100644
index 0000000000..74fe45aa77
--- /dev/null
+++ b/lib/compiler/doc/src/ref_man.xml
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE application SYSTEM "application.dtd">
+
+<application xmlns:xi="http://www.w3.org/2001/XInclude">
+  <header>
+    <copyright>
+      <year>1996</year><year>2009</year>
+      <holder>Ericsson AB. All Rights Reserved.</holder>
+    </copyright>
+    <legalnotice>
+      The contents of this file are subject to the Erlang Public License,
+      Version 1.1, (the "License"); you may not use this file except in
+      compliance with the License. You should have received a copy of the
+      Erlang Public License along with this software. If not, it can be
+      retrieved online at http://www.erlang.org/.
+    
+      Software distributed under the License is distributed on an "AS IS"
+      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+      the License for the specific language governing rights and limitations
+      under the License.
+    
+    </legalnotice>
+
+    <title>Compiler Reference Manual</title>
+    <prepared>Robert Virding</prepared>
+    <docno></docno>
+    <date>1997-05-02</date>
+    <rev>1.1.2</rev>
+    <file>application.sgml</file>
+  </header>
+  <description>
+    <p>The <em>Compiler</em> application compiles Erlang
+      code to byte-code. The highly compact byte-code is executed by
+      the Erlang emulator.</p>
+  </description>
+  <xi:include href="compile.xml"/>
+</application>
+
diff --git a/lib/compiler/doc/src/user_guide.gif b/lib/compiler/doc/src/user_guide.gif
new file mode 100644
index 0000000000..e6275a803d
--- /dev/null
+++ b/lib/compiler/doc/src/user_guide.gif
diff --git a/lib/compiler/doc/src/warning.gif b/lib/compiler/doc/src/warning.gif
new file mode 100644
index 0000000000..96af52360e
--- /dev/null
+++ b/lib/compiler/doc/src/warning.gif