Initial checkin of GCC 4.9.0 from trunk (r208799).

Change-Id: I48a3c08bb98542aa215912a75f03c0890e497dba

1 files changed, 4790 insertions, 0 deletions

diff --git a/gcc-4.9/gcc/doc/install.texi b/gcc-4.9/gcc/doc/install.texi
new file mode 100644
index 000000000..dc040cbc3
--- /dev/null
+++ b/gcc-4.9/gcc/doc/install.texi
@@ -0,0 +1,4790 @@
+\input texinfo.tex    @c -*-texinfo-*-
+@c @ifnothtml
+@c %**start of header
+@setfilename gccinstall.info
+@settitle Installing GCC
+@setchapternewpage odd
+@c %**end of header
+@c @end ifnothtml
+
+@include gcc-common.texi
+
+@c Specify title for specific html page
+@ifset indexhtml
+@settitle Installing GCC
+@end ifset
+@ifset specifichtml
+@settitle Host/Target specific installation notes for GCC
+@end ifset
+@ifset prerequisiteshtml
+@settitle Prerequisites for GCC
+@end ifset
+@ifset downloadhtml
+@settitle Downloading GCC
+@end ifset
+@ifset configurehtml
+@settitle Installing GCC: Configuration
+@end ifset
+@ifset buildhtml
+@settitle Installing GCC: Building
+@end ifset
+@ifset testhtml
+@settitle Installing GCC: Testing
+@end ifset
+@ifset finalinstallhtml
+@settitle Installing GCC: Final installation
+@end ifset
+@ifset binarieshtml
+@settitle Installing GCC: Binaries
+@end ifset
+@ifset oldhtml
+@settitle Installing GCC: Old documentation
+@end ifset
+@ifset gfdlhtml
+@settitle Installing GCC: GNU Free Documentation License
+@end ifset
+
+@c Copyright (C) 1988-2014 Free Software Foundation, Inc.
+@c *** Converted to texinfo by Dean Wakerley, dean@wakerley.com
+
+@c IMPORTANT: whenever you modify this file, run `install.texi2html' to
+@c test the generation of HTML documents for the gcc.gnu.org web pages.
+@c
+@c Do not use @footnote{} in this file as it breaks install.texi2html!
+
+@c Include everything if we're not making html
+@ifnothtml
+@set indexhtml
+@set specifichtml
+@set prerequisiteshtml
+@set downloadhtml
+@set configurehtml
+@set buildhtml
+@set testhtml
+@set finalinstallhtml
+@set binarieshtml
+@set oldhtml
+@set gfdlhtml
+@end ifnothtml
+
+@c Part 2 Summary Description and Copyright
+@copying
+Copyright @copyright{} 1988-2014 Free Software Foundation, Inc.
+@sp 1
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with no
+Invariant Sections, the Front-Cover texts being (a) (see below), and
+with the Back-Cover Texts being (b) (see below).  A copy of the
+license is included in the section entitled ``@uref{./gfdl.html,,GNU
+Free Documentation License}''.
+
+(a) The FSF's Front-Cover Text is:
+
+     A GNU Manual
+
+(b) The FSF's Back-Cover Text is:
+
+     You have freedom to copy and modify this GNU Manual, like GNU
+     software.  Copies published by the Free Software Foundation raise
+     funds for GNU development.
+@end copying
+@ifinfo
+@insertcopying
+@end ifinfo
+@dircategory Software development
+@direntry
+* gccinstall: (gccinstall).    Installing the GNU Compiler Collection.
+@end direntry
+
+@c Part 3 Titlepage and Copyright
+@titlepage
+@title Installing GCC
+@versionsubtitle
+
+@c The following two commands start the copyright page.
+@page
+@vskip 0pt plus 1filll
+@insertcopying
+@end titlepage
+
+@c Part 4 Top node, Master Menu, and/or Table of Contents
+@ifinfo
+@node    Top, , , (dir)
+@comment node-name, next,          Previous, up
+
+@menu
+* Installing GCC::  This document describes the generic installation
+                    procedure for GCC as well as detailing some target
+                    specific installation instructions.
+
+* Specific::        Host/target specific installation notes for GCC.
+* Binaries::        Where to get pre-compiled binaries.
+
+* Old::             Old installation documentation.
+
+* GNU Free Documentation License:: How you can copy and share this manual.
+* Concept Index::   This index has two entries.
+@end menu
+@end ifinfo
+
+@iftex
+@contents
+@end iftex
+
+@c Part 5 The Body of the Document
+@c ***Installing GCC**********************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Installing GCC, Binaries, , Top
+@end ifnothtml
+@ifset indexhtml
+@ifnothtml
+@chapter Installing GCC
+@end ifnothtml
+
+The latest version of this document is always available at
+@uref{http://gcc.gnu.org/install/,,http://gcc.gnu.org/install/}.
+It refers to the current development sources, instructions for
+specific released versions are included with the sources.
+
+This document describes the generic installation procedure for GCC as well
+as detailing some target specific installation instructions.
+
+GCC includes several components that previously were separate distributions
+with their own installation instructions.  This document supersedes all
+package-specific installation instructions.
+
+@emph{Before} starting the build/install procedure please check the
+@ifnothtml
+@ref{Specific, host/target specific installation notes}.
+@end ifnothtml
+@ifhtml
+@uref{specific.html,,host/target specific installation notes}.
+@end ifhtml
+We recommend you browse the entire generic installation instructions before
+you proceed.
+
+Lists of successful builds for released versions of GCC are
+available at @uref{http://gcc.gnu.org/buildstat.html}.
+These lists are updated as new information becomes available.
+
+The installation procedure itself is broken into five steps.
+
+@ifinfo
+@menu
+* Prerequisites::
+* Downloading the source::
+* Configuration::
+* Building::
+* Testing:: (optional)
+* Final install::
+@end menu
+@end ifinfo
+@ifhtml
+@enumerate
+@item
+@uref{prerequisites.html,,Prerequisites}
+@item
+@uref{download.html,,Downloading the source}
+@item
+@uref{configure.html,,Configuration}
+@item
+@uref{build.html,,Building}
+@item
+@uref{test.html,,Testing} (optional)
+@item
+@uref{finalinstall.html,,Final install}
+@end enumerate
+@end ifhtml
+
+Please note that GCC does not support @samp{make uninstall} and probably
+won't do so in the near future as this would open a can of worms.  Instead,
+we suggest that you install GCC into a directory of its own and simply
+remove that directory when you do not need that specific version of GCC
+any longer, and, if shared libraries are installed there as well, no
+more binaries exist that use them.
+
+@ifhtml
+There are also some @uref{old.html,,old installation instructions},
+which are mostly obsolete but still contain some information which has
+not yet been merged into the main part of this manual.
+@end ifhtml
+
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+
+@insertcopying
+@end ifhtml
+@end ifset
+
+@c ***Prerequisites**************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Prerequisites, Downloading the source, , Installing GCC
+@end ifnothtml
+@ifset prerequisiteshtml
+@ifnothtml
+@chapter Prerequisites
+@end ifnothtml
+@cindex Prerequisites
+
+GCC requires that various tools and packages be available for use in the
+build procedure.  Modifying GCC sources requires additional tools
+described below.
+
+@heading Tools/packages necessary for building GCC
+@table @asis
+@item ISO C++98 compiler
+Necessary to bootstrap GCC, although versions of GCC prior
+to 4.8 also allow bootstrapping with a ISO C89 compiler and versions
+of GCC prior to 3.4 also allow bootstrapping with a traditional
+(K&R) C compiler.
+
+To build all languages in a cross-compiler or other configuration where
+3-stage bootstrap is not performed, you need to start with an existing
+GCC binary (version 3.4 or later) because source code for language
+frontends other than C might use GCC extensions.
+
+Note that to bootstrap GCC with versions of GCC earlier than 3.4, you
+may need to use @option{--disable-stage1-checking}, though
+bootstrapping the compiler with such earlier compilers is strongly
+discouraged.
+
+@item C standard library and headers
+
+In order to build GCC, the C standard library and headers must be present
+for all target variants for which target libraries will be built (and not
+only the variant of the host C++ compiler).
+
+This affects the popular @samp{x86_64-unknown-linux-gnu} platform (among
+other multilib targets), for which 64-bit (@samp{x86_64}) and 32-bit
+(@samp{i386}) libc headers are usually packaged separately. If you do a
+build of a native compiler on @samp{x86_64-unknown-linux-gnu}, make sure you
+either have the 32-bit libc developer package properly installed (the exact
+name of the package depends on your distro) or you must build GCC as a
+64-bit only compiler by configuring with the option
+@option{--disable-multilib}.  Otherwise, you may encounter an error such as
+@samp{fatal error: gnu/stubs-32.h: No such file}
+
+@item GNAT
+
+In order to build the Ada compiler (GNAT) you must already have GNAT
+installed because portions of the Ada frontend are written in Ada (with
+GNAT extensions.)  Refer to the Ada installation instructions for more
+specific information.
+
+@item A ``working'' POSIX compatible shell, or GNU bash
+
+Necessary when running @command{configure} because some
+@command{/bin/sh} shells have bugs and may crash when configuring the
+target libraries.  In other cases, @command{/bin/sh} or @command{ksh}
+have disastrous corner-case performance problems.  This
+can cause target @command{configure} runs to literally take days to
+complete in some cases.
+
+So on some platforms @command{/bin/ksh} is sufficient, on others it
+isn't.  See the host/target specific instructions for your platform, or
+use @command{bash} to be sure.  Then set @env{CONFIG_SHELL} in your
+environment to your ``good'' shell prior to running
+@command{configure}/@command{make}.
+
+@command{zsh} is not a fully compliant POSIX shell and will not
+work when configuring GCC@.
+
+@item A POSIX or SVR4 awk
+
+Necessary for creating some of the generated source files for GCC@.
+If in doubt, use a recent GNU awk version, as some of the older ones
+are broken.  GNU awk version 3.1.5 is known to work.
+
+@item GNU binutils
+
+Necessary in some circumstances, optional in others.  See the
+host/target specific instructions for your platform for the exact
+requirements.
+
+@item gzip version 1.2.4 (or later) or
+@itemx bzip2 version 1.0.2 (or later)
+
+Necessary to uncompress GCC @command{tar} files when source code is
+obtained via FTP mirror sites.
+
+@item GNU make version 3.80 (or later)
+
+You must have GNU make installed to build GCC@.
+
+@item GNU tar version 1.14 (or later)
+
+Necessary (only on some platforms) to untar the source code.  Many
+systems' @command{tar} programs will also work, only try GNU
+@command{tar} if you have problems.
+
+@item Perl version 5.6.1 (or later)
+
+Necessary when targeting Darwin, building @samp{libstdc++},
+and not using @option{--disable-symvers}.
+Necessary when targeting Solaris 2 with Sun @command{ld} and not using
+@option{--disable-symvers}.  The bundled @command{perl} in Solaris@tie{}8
+and up works.
+
+Necessary when regenerating @file{Makefile} dependencies in libiberty.
+Necessary when regenerating @file{libiberty/functions.texi}.
+Necessary when generating manpages from Texinfo manuals.
+Used by various scripts to generate some files included in SVN (mainly
+Unicode-related and rarely changing) from source tables.
+
+@item @command{jar}, or InfoZIP (@command{zip} and @command{unzip})
+
+Necessary to build libgcj, the GCJ runtime.
+
+@end table
+
+Several support libraries are necessary to build GCC, some are required,
+others optional.  While any sufficiently new version of required tools
+usually work, library requirements are generally stricter.  Newer
+versions may work in some cases, but it's safer to use the exact
+versions documented.  We appreciate bug reports about problems with
+newer versions, though.  If your OS vendor provides packages for the
+support libraries then using those packages may be the simplest way to
+install the libraries.
+
+@table @asis
+@item GNU Multiple Precision Library (GMP) version 4.3.2 (or later)
+
+Necessary to build GCC@.  If a GMP source distribution is found in a
+subdirectory of your GCC sources named @file{gmp}, it will be built
+together with GCC.  Alternatively, if GMP is already installed but it
+is not in your library search path, you will have to configure with the
+@option{--with-gmp} configure option.  See also @option{--with-gmp-lib}
+and @option{--with-gmp-include}.
+
+@item MPFR Library version 2.4.2 (or later)
+
+Necessary to build GCC@.  It can be downloaded from
+@uref{http://www.mpfr.org/}.  If an MPFR source distribution is found
+in a subdirectory of your GCC sources named @file{mpfr}, it will be
+built together with GCC.  Alternatively, if MPFR is already installed
+but it is not in your default library search path, the
+@option{--with-mpfr} configure option should be used.  See also
+@option{--with-mpfr-lib} and @option{--with-mpfr-include}.
+
+@item MPC Library version 0.8.1 (or later)
+
+Necessary to build GCC@.  It can be downloaded from
+@uref{http://www.multiprecision.org/}.  If an MPC source distribution
+is found in a subdirectory of your GCC sources named @file{mpc}, it
+will be built together with GCC.  Alternatively, if MPC is already
+installed but it is not in your default library search path, the
+@option{--with-mpc} configure option should be used.  See also
+@option{--with-mpc-lib} and @option{--with-mpc-include}.
+
+@item ISL Library version 0.12.2
+
+Necessary to build GCC with the Graphite loop optimizations.
+It can be downloaded from @uref{ftp://gcc.gnu.org/pub/gcc/infrastructure/}
+as @file{isl-0.12.2.tar.bz2}.  If an ISL source distribution is found
+in a subdirectory of your GCC sources named @file{isl}, it will be
+built together with GCC.  Alternatively, the @option{--with-isl} configure
+option should be used if ISL is not installed in your default library
+search path.
+
+@item CLooG 0.18.1
+
+Necessary to build GCC with the Graphite loop optimizations.  It can be
+downloaded from @uref{ftp://gcc.gnu.org/pub/gcc/infrastructure/} as
+@file{cloog-0.18.1.tar.gz}.  If a CLooG source distribution is found
+in a subdirectory of your GCC sources named @file{cloog}, it will be
+built together with GCC.  Alternatively, the @option{--with-cloog} configure
+option should be used if CLooG is not installed in your default library search
+path.
+
+If you want to install CLooG separately it needs to be built against
+ISL 0.12.2 by using the @option{--with-isl=system} to direct CLooG to pick
+up an already installed ISL.  Using the ISL library as bundled with CLooG
+is not supported.
+
+@end table
+
+@heading Tools/packages necessary for modifying GCC
+@table @asis
+@item autoconf version 2.64
+@itemx GNU m4 version 1.4.6 (or later)
+
+Necessary when modifying @file{configure.ac}, @file{aclocal.m4}, etc.@:
+to regenerate @file{configure} and @file{config.in} files.
+
+@item automake version 1.11.1
+
+Necessary when modifying a @file{Makefile.am} file to regenerate its
+associated @file{Makefile.in}.
+
+Much of GCC does not use automake, so directly edit the @file{Makefile.in}
+file.  Specifically this applies to the @file{gcc}, @file{intl},
+@file{libcpp}, @file{libiberty}, @file{libobjc} directories as well
+as any of their subdirectories.
+
+For directories that use automake, GCC requires the latest release in
+the 1.11 series, which is currently 1.11.1.  When regenerating a directory
+to a newer version, please update all the directories using an older 1.11
+to the latest released version.
+
+@item gettext version 0.14.5 (or later)
+
+Needed to regenerate @file{gcc.pot}.
+
+@item gperf version 2.7.2 (or later)
+
+Necessary when modifying @command{gperf} input files, e.g.@:
+@file{gcc/cp/cfns.gperf} to regenerate its associated header file, e.g.@:
+@file{gcc/cp/cfns.h}.
+
+@item DejaGnu 1.4.4
+@itemx Expect
+@itemx Tcl
+
+Necessary to run the GCC testsuite; see the section on testing for
+details.  Tcl 8.6 has a known regression in RE pattern handling that
+make parts of the testsuite fail.  See
+@uref{http://core.tcl.tk/tcl/tktview/267b7e2334ee2e9de34c4b00d6e72e2f1997085f}
+for more information.
+
+@item autogen version 5.5.4 (or later) and
+@itemx guile version 1.4.1 (or later)
+
+Necessary to regenerate @file{fixinc/fixincl.x} from
+@file{fixinc/inclhack.def} and @file{fixinc/*.tpl}.
+
+Necessary to run @samp{make check} for @file{fixinc}.
+
+Necessary to regenerate the top level @file{Makefile.in} file from
+@file{Makefile.tpl} and @file{Makefile.def}.
+
+@item Flex version 2.5.4 (or later)
+
+Necessary when modifying @file{*.l} files.
+
+Necessary to build GCC during development because the generated output
+files are not included in the SVN repository.  They are included in
+releases.
+
+@item Texinfo version 4.7 (or later)
+
+Necessary for running @command{makeinfo} when modifying @file{*.texi}
+files to test your changes.
+
+Necessary for running @command{make dvi} or @command{make pdf} to
+create printable documentation in DVI or PDF format.  Texinfo version
+4.8 or later is required for @command{make pdf}.
+
+Necessary to build GCC documentation during development because the
+generated output files are not included in the SVN repository.  They are
+included in releases.
+
+@item @TeX{} (any working version)
+
+Necessary for running @command{texi2dvi} and @command{texi2pdf}, which
+are used when running @command{make dvi} or @command{make pdf} to create
+DVI or PDF files, respectively.
+
+@item SVN (any version)
+@itemx SSH (any version)
+
+Necessary to access the SVN repository.  Public releases and weekly
+snapshots of the development sources are also available via FTP@.
+
+@item GNU diffutils version 2.7 (or later)
+
+Useful when submitting patches for the GCC source code.
+
+@item patch version 2.5.4 (or later)
+
+Necessary when applying patches, created with @command{diff}, to one's
+own sources.
+
+@item ecj1
+@itemx gjavah
+
+If you wish to modify @file{.java} files in libjava, you will need to
+configure with @option{--enable-java-maintainer-mode}, and you will need
+to have executables named @command{ecj1} and @command{gjavah} in your path.
+The @command{ecj1} executable should run the Eclipse Java compiler via
+the GCC-specific entry point.  You can download a suitable jar from
+@uref{ftp://sourceware.org/pub/java/}, or by running the script
+@command{contrib/download_ecj}.
+
+@item antlr.jar version 2.7.1 (or later)
+@itemx antlr binary
+
+If you wish to build the @command{gjdoc} binary in libjava, you will
+need to have an @file{antlr.jar} library available. The library is
+searched for in system locations but can be specified with
+@option{--with-antlr-jar=} instead.  When configuring with
+@option{--enable-java-maintainer-mode}, you will need to have one of
+the executables named @command{cantlr}, @command{runantlr} or
+@command{antlr} in your path.
+
+@end table
+
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+
+@c ***Downloading the source**************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Downloading the source, Configuration, Prerequisites, Installing GCC
+@end ifnothtml
+@ifset downloadhtml
+@ifnothtml
+@chapter Downloading GCC
+@end ifnothtml
+@cindex Downloading GCC
+@cindex Downloading the Source
+
+GCC is distributed via @uref{http://gcc.gnu.org/svn.html,,SVN} and FTP
+tarballs compressed with @command{gzip} or
+@command{bzip2}.
+
+Please refer to the @uref{http://gcc.gnu.org/releases.html,,releases web page}
+for information on how to obtain GCC@.
+
+The source distribution includes the C, C++, Objective-C, Fortran, Java,
+and Ada (in the case of GCC 3.1 and later) compilers, as well as
+runtime libraries for C++, Objective-C, Fortran, and Java.
+For previous versions these were downloadable as separate components such
+as the core GCC distribution, which included the C language front end and
+shared components, and language-specific distributions including the
+language front end and the language runtime (where appropriate).
+
+If you also intend to build binutils (either to upgrade an existing
+installation or for use in place of the corresponding tools of your
+OS), unpack the binutils distribution either in the same directory or
+a separate one.  In the latter case, add symbolic links to any
+components of the binutils you intend to build alongside the compiler
+(@file{bfd}, @file{binutils}, @file{gas}, @file{gprof}, @file{ld},
+@file{opcodes}, @dots{}) to the directory containing the GCC sources.
+
+Likewise the GMP, MPFR and MPC libraries can be automatically built
+together with GCC.  Unpack the GMP, MPFR and/or MPC source
+distributions in the directory containing the GCC sources and rename
+their directories to @file{gmp}, @file{mpfr} and @file{mpc},
+respectively (or use symbolic links with the same name).
+
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+
+@c ***Configuration***********************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Configuration, Building, Downloading the source, Installing GCC
+@end ifnothtml
+@ifset configurehtml
+@ifnothtml
+@chapter Installing GCC: Configuration
+@end ifnothtml
+@cindex Configuration
+@cindex Installing GCC: Configuration
+
+Like most GNU software, GCC must be configured before it can be built.
+This document describes the recommended configuration procedure
+for both native and cross targets.
+
+We use @var{srcdir} to refer to the toplevel source directory for
+GCC; we use @var{objdir} to refer to the toplevel build/object directory.
+
+If you obtained the sources via SVN, @var{srcdir} must refer to the top
+@file{gcc} directory, the one where the @file{MAINTAINERS} file can be
+found, and not its @file{gcc} subdirectory, otherwise the build will fail.
+
+If either @var{srcdir} or @var{objdir} is located on an automounted NFS
+file system, the shell's built-in @command{pwd} command will return
+temporary pathnames.  Using these can lead to various sorts of build
+problems.  To avoid this issue, set the @env{PWDCMD} environment
+variable to an automounter-aware @command{pwd} command, e.g.,
+@command{pawd} or @samp{amq -w}, during the configuration and build
+phases.
+
+First, we @strong{highly} recommend that GCC be built into a
+separate directory from the sources which does @strong{not} reside
+within the source tree.  This is how we generally build GCC; building
+where @var{srcdir} == @var{objdir} should still work, but doesn't
+get extensive testing; building where @var{objdir} is a subdirectory
+of @var{srcdir} is unsupported.
+
+If you have previously built GCC in the same directory for a
+different target machine, do @samp{make distclean} to delete all files
+that might be invalid.  One of the files this deletes is @file{Makefile};
+if @samp{make distclean} complains that @file{Makefile} does not exist
+or issues a message like ``don't know how to make distclean'' it probably
+means that the directory is already suitably clean.  However, with the
+recommended method of building in a separate @var{objdir}, you should
+simply use a different @var{objdir} for each target.
+
+Second, when configuring a native system, either @command{cc} or
+@command{gcc} must be in your path or you must set @env{CC} in
+your environment before running configure.  Otherwise the configuration
+scripts may fail.
+
+@ignore
+Note that the bootstrap compiler and the resulting GCC must be link
+compatible, else the bootstrap will fail with linker errors about
+incompatible object file formats.  Several multilibed targets are
+affected by this requirement, see
+@ifnothtml
+@ref{Specific, host/target specific installation notes}.
+@end ifnothtml
+@ifhtml
+@uref{specific.html,,host/target specific installation notes}.
+@end ifhtml
+@end ignore
+
+To configure GCC:
+
+@smallexample
+% mkdir @var{objdir}
+% cd @var{objdir}
+% @var{srcdir}/configure [@var{options}] [@var{target}]
+@end smallexample
+
+@heading Distributor options
+
+If you will be distributing binary versions of GCC, with modifications
+to the source code, you should use the options described in this
+section to make clear that your version contains modifications.
+
+@table @code
+@item --with-pkgversion=@var{version}
+Specify a string that identifies your package.  You may wish
+to include a build number or build date.  This version string will be
+included in the output of @command{gcc --version}.  This suffix does
+not replace the default version string, only the @samp{GCC} part.
+
+The default value is @samp{GCC}.
+
+@item --with-bugurl=@var{url}
+Specify the URL that users should visit if they wish to report a bug.
+You are of course welcome to forward bugs reported to you to the FSF,
+if you determine that they are not bugs in your modifications.
+
+The default value refers to the FSF's GCC bug tracker.
+
+@end table
+
+@heading Target specification
+@itemize @bullet
+@item
+GCC has code to correctly determine the correct value for @var{target}
+for nearly all native systems.  Therefore, we highly recommend you do
+not provide a configure target when configuring a native compiler.
+
+@item
+@var{target} must be specified as @option{--target=@var{target}}
+when configuring a cross compiler; examples of valid targets would be
+m68k-elf, sh-elf, etc.
+
+@item
+Specifying just @var{target} instead of @option{--target=@var{target}}
+implies that the host defaults to @var{target}.
+@end itemize
+
+
+@heading Options specification
+
+Use @var{options} to override several configure time options for
+GCC@.  A list of supported @var{options} follows; @samp{configure
+--help} may list other options, but those not listed below may not
+work and should not normally be used.
+
+Note that each @option{--enable} option has a corresponding
+@option{--disable} option and that each @option{--with} option has a
+corresponding @option{--without} option.
+
+@table @code
+@item --prefix=@var{dirname}
+Specify the toplevel installation
+directory.  This is the recommended way to install the tools into a directory
+other than the default.  The toplevel installation directory defaults to
+@file{/usr/local}.
+
+We @strong{highly} recommend against @var{dirname} being the same or a
+subdirectory of @var{objdir} or vice versa.  If specifying a directory
+beneath a user's home directory tree, some shells will not expand
+@var{dirname} correctly if it contains the @samp{~} metacharacter; use
+@env{$HOME} instead.
+
+The following standard @command{autoconf} options are supported.  Normally you
+should not need to use these options.
+@table @code
+@item --exec-prefix=@var{dirname}
+Specify the toplevel installation directory for architecture-dependent
+files.  The default is @file{@var{prefix}}.
+
+@item --bindir=@var{dirname}
+Specify the installation directory for the executables called by users
+(such as @command{gcc} and @command{g++}).  The default is
+@file{@var{exec-prefix}/bin}.
+
+@item --libdir=@var{dirname}
+Specify the installation directory for object code libraries and
+internal data files of GCC@.  The default is @file{@var{exec-prefix}/lib}.
+
+@item --libexecdir=@var{dirname}
+Specify the installation directory for internal executables of GCC@.
+The default is @file{@var{exec-prefix}/libexec}.
+
+@item --with-slibdir=@var{dirname}
+Specify the installation directory for the shared libgcc library.  The
+default is @file{@var{libdir}}.
+
+@item --datarootdir=@var{dirname}
+Specify the root of the directory tree for read-only architecture-independent
+data files referenced by GCC@.  The default is @file{@var{prefix}/share}.
+
+@item --infodir=@var{dirname}
+Specify the installation directory for documentation in info format.
+The default is @file{@var{datarootdir}/info}.
+
+@item --datadir=@var{dirname}
+Specify the installation directory for some architecture-independent
+data files referenced by GCC@.  The default is @file{@var{datarootdir}}.
+
+@item --docdir=@var{dirname}
+Specify the installation directory for documentation files (other
+than Info) for GCC@.  The default is @file{@var{datarootdir}/doc}.
+
+@item --htmldir=@var{dirname}
+Specify the installation directory for HTML documentation files.
+The default is @file{@var{docdir}}.
+
+@item --pdfdir=@var{dirname}
+Specify the installation directory for PDF documentation files.
+The default is @file{@var{docdir}}.
+
+@item --mandir=@var{dirname}
+Specify the installation directory for manual pages.  The default is
+@file{@var{datarootdir}/man}.  (Note that the manual pages are only extracts
+from the full GCC manuals, which are provided in Texinfo format.  The manpages
+are derived by an automatic conversion process from parts of the full
+manual.)
+
+@item --with-gxx-include-dir=@var{dirname}
+Specify
+the installation directory for G++ header files.  The default depends
+on other configuration options, and differs between cross and native
+configurations.
+
+@item --with-specs=@var{specs}
+Specify additional command line driver SPECS.
+This can be useful if you need to turn on a non-standard feature by
+default without modifying the compiler's source code, for instance
+@option{--with-specs=%@{!fcommon:%@{!fno-common:-fno-common@}@}}.
+@ifnothtml
+@xref{Spec Files,, Specifying subprocesses and the switches to pass to them,
+gcc, Using the GNU Compiler Collection (GCC)},
+@end ifnothtml
+@ifhtml
+See ``Spec Files'' in the main manual
+@end ifhtml
+
+@end table
+
+@item --program-prefix=@var{prefix}
+GCC supports some transformations of the names of its programs when
+installing them.  This option prepends @var{prefix} to the names of
+programs to install in @var{bindir} (see above).  For example, specifying
+@option{--program-prefix=foo-} would result in @samp{gcc}
+being installed as @file{/usr/local/bin/foo-gcc}.
+
+@item --program-suffix=@var{suffix}
+Appends @var{suffix} to the names of programs to install in @var{bindir}
+(see above).  For example, specifying @option{--program-suffix=-3.1}
+would result in @samp{gcc} being installed as
+@file{/usr/local/bin/gcc-3.1}.
+
+@item --program-transform-name=@var{pattern}
+Applies the @samp{sed} script @var{pattern} to be applied to the names
+of programs to install in @var{bindir} (see above).  @var{pattern} has to
+consist of one or more basic @samp{sed} editing commands, separated by
+semicolons.  For example, if you want the @samp{gcc} program name to be
+transformed to the installed program @file{/usr/local/bin/myowngcc} and
+the @samp{g++} program name to be transformed to
+@file{/usr/local/bin/gspecial++} without changing other program names,
+you could use the pattern
+@option{--program-transform-name='s/^gcc$/myowngcc/; s/^g++$/gspecial++/'}
+to achieve this effect.
+
+All three options can be combined and used together, resulting in more
+complex conversion patterns.  As a basic rule, @var{prefix} (and
+@var{suffix}) are prepended (appended) before further transformations
+can happen with a special transformation script @var{pattern}.
+
+As currently implemented, this option only takes effect for native
+builds; cross compiler binaries' names are not transformed even when a
+transformation is explicitly asked for by one of these options.
+
+For native builds, some of the installed programs are also installed
+with the target alias in front of their name, as in
+@samp{i686-pc-linux-gnu-gcc}.  All of the above transformations happen
+before the target alias is prepended to the name---so, specifying
+@option{--program-prefix=foo-} and @option{program-suffix=-3.1}, the
+resulting binary would be installed as
+@file{/usr/local/bin/i686-pc-linux-gnu-foo-gcc-3.1}.
+
+As a last shortcoming, none of the installed Ada programs are
+transformed yet, which will be fixed in some time.
+
+@item --with-local-prefix=@var{dirname}
+Specify the
+installation directory for local include files.  The default is
+@file{/usr/local}.  Specify this option if you want the compiler to
+search directory @file{@var{dirname}/include} for locally installed
+header files @emph{instead} of @file{/usr/local/include}.
+
+You should specify @option{--with-local-prefix} @strong{only} if your
+site has a different convention (not @file{/usr/local}) for where to put
+site-specific files.
+
+The default value for @option{--with-local-prefix} is @file{/usr/local}
+regardless of the value of @option{--prefix}.  Specifying
+@option{--prefix} has no effect on which directory GCC searches for
+local header files.  This may seem counterintuitive, but actually it is
+logical.
+
+The purpose of @option{--prefix} is to specify where to @emph{install
+GCC}.  The local header files in @file{/usr/local/include}---if you put
+any in that directory---are not part of GCC@.  They are part of other
+programs---perhaps many others.  (GCC installs its own header files in
+another directory which is based on the @option{--prefix} value.)
+
+Both the local-prefix include directory and the GCC-prefix include
+directory are part of GCC's ``system include'' directories.  Although these
+two directories are not fixed, they need to be searched in the proper
+order for the correct processing of the include_next directive.  The
+local-prefix include directory is searched before the GCC-prefix
+include directory.  Another characteristic of system include directories
+is that pedantic warnings are turned off for headers in these directories.
+
+Some autoconf macros add @option{-I @var{directory}} options to the
+compiler command line, to ensure that directories containing installed
+packages' headers are searched.  When @var{directory} is one of GCC's
+system include directories, GCC will ignore the option so that system
+directories continue to be processed in the correct order.  This
+may result in a search order different from what was specified but the
+directory will still be searched.
+
+GCC automatically searches for ordinary libraries using
+@env{GCC_EXEC_PREFIX}.  Thus, when the same installation prefix is
+used for both GCC and packages, GCC will automatically search for
+both headers and libraries.  This provides a configuration that is
+easy to use.  GCC behaves in a manner similar to that when it is
+installed as a system compiler in @file{/usr}.
+
+Sites that need to install multiple versions of GCC may not want to
+use the above simple configuration.  It is possible to use the
+@option{--program-prefix}, @option{--program-suffix} and
+@option{--program-transform-name} options to install multiple versions
+into a single directory, but it may be simpler to use different prefixes
+and the @option{--with-local-prefix} option to specify the location of the
+site-specific files for each version.  It will then be necessary for
+users to specify explicitly the location of local site libraries
+(e.g., with @env{LIBRARY_PATH}).
+
+The same value can be used for both @option{--with-local-prefix} and
+@option{--prefix} provided it is not @file{/usr}.  This can be used
+to avoid the default search of @file{/usr/local/include}.
+
+@strong{Do not} specify @file{/usr} as the @option{--with-local-prefix}!
+The directory you use for @option{--with-local-prefix} @strong{must not}
+contain any of the system's standard header files.  If it did contain
+them, certain programs would be miscompiled (including GNU Emacs, on
+certain targets), because this would override and nullify the header
+file corrections made by the @command{fixincludes} script.
+
+Indications are that people who use this option use it based on mistaken
+ideas of what it is for.  People use it as if it specified where to
+install part of GCC@.  Perhaps they make this assumption because
+installing GCC creates the directory.
+
+@item --with-native-system-header-dir=@var{dirname}
+Specifies that @var{dirname} is the directory that contains native system
+header files, rather than @file{/usr/include}.  This option is most useful
+if you are creating a compiler that should be isolated from the system
+as much as possible.  It is most commonly used with the
+@option{--with-sysroot} option and will cause GCC to search
+@var{dirname} inside the system root specified by that option.
+
+@item --enable-shared[=@var{package}[,@dots{}]]
+Build shared versions of libraries, if shared libraries are supported on
+the target platform.  Unlike GCC 2.95.x and earlier, shared libraries
+are enabled by default on all platforms that support shared libraries.
+
+If a list of packages is given as an argument, build shared libraries
+only for the listed packages.  For other packages, only static libraries
+will be built.  Package names currently recognized in the GCC tree are
+@samp{libgcc} (also known as @samp{gcc}), @samp{libstdc++} (not
+@samp{libstdc++-v3}), @samp{libffi}, @samp{zlib}, @samp{boehm-gc},
+@samp{ada}, @samp{libada}, @samp{libjava}, @samp{libgo}, and @samp{libobjc}.
+Note @samp{libiberty} does not support shared libraries at all.
+
+Use @option{--disable-shared} to build only static libraries.  Note that
+@option{--disable-shared} does not accept a list of package names as
+argument, only @option{--enable-shared} does.
+
+Contrast with @option{--enable-host-shared}, which affects @emph{host}
+code.
+
+@item --enable-host-shared
+Specify that the @emph{host} code should be built into position-independent
+machine code (with -fPIC), allowing it to be used within shared libraries,
+but yielding a slightly slower compiler.
+
+Currently this option is only of use to people developing GCC itself.
+
+Contrast with @option{--enable-shared}, which affects @emph{target}
+libraries.
+
+@item @anchor{with-gnu-as}--with-gnu-as
+Specify that the compiler should assume that the
+assembler it finds is the GNU assembler.  However, this does not modify
+the rules to find an assembler and will result in confusion if the
+assembler found is not actually the GNU assembler.  (Confusion may also
+result if the compiler finds the GNU assembler but has not been
+configured with @option{--with-gnu-as}.)  If you have more than one
+assembler installed on your system, you may want to use this option in
+connection with @option{--with-as=@var{pathname}} or
+@option{--with-build-time-tools=@var{pathname}}.
+
+The following systems are the only ones where it makes a difference
+whether you use the GNU assembler.  On any other system,
+@option{--with-gnu-as} has no effect.
+
+@itemize @bullet
+@item @samp{hppa1.0-@var{any}-@var{any}}
+@item @samp{hppa1.1-@var{any}-@var{any}}
+@item @samp{sparc-sun-solaris2.@var{any}}
+@item @samp{sparc64-@var{any}-solaris2.@var{any}}
+@end itemize
+
+@item @anchor{with-as}--with-as=@var{pathname}
+Specify that the compiler should use the assembler pointed to by
+@var{pathname}, rather than the one found by the standard rules to find
+an assembler, which are:
+@itemize @bullet
+@item
+Unless GCC is being built with a cross compiler, check the
+@file{@var{libexec}/gcc/@var{target}/@var{version}} directory.
+@var{libexec} defaults to @file{@var{exec-prefix}/libexec};
+@var{exec-prefix} defaults to @var{prefix}, which
+defaults to @file{/usr/local} unless overridden by the
+@option{--prefix=@var{pathname}} switch described above.  @var{target}
+is the target system triple, such as @samp{sparc-sun-solaris2.7}, and
+@var{version} denotes the GCC version, such as 3.0.
+
+@item
+If the target system is the same that you are building on, check
+operating system specific directories (e.g.@: @file{/usr/ccs/bin} on
+Sun Solaris 2).
+
+@item
+Check in the @env{PATH} for a tool whose name is prefixed by the
+target system triple.
+
+@item
+Check in the @env{PATH} for a tool whose name is not prefixed by the
+target system triple, if the host and target system triple are
+the same (in other words, we use a host tool if it can be used for
+the target as well).
+@end itemize
+
+You may want to use @option{--with-as} if no assembler
+is installed in the directories listed above, or if you have multiple
+assemblers installed and want to choose one that is not found by the
+above rules.
+
+@item @anchor{with-gnu-ld}--with-gnu-ld
+Same as @uref{#with-gnu-as,,@option{--with-gnu-as}}
+but for the linker.
+
+@item --with-ld=@var{pathname}
+Same as @uref{#with-as,,@option{--with-as}}
+but for the linker.
+
+@item --with-stabs
+Specify that stabs debugging
+information should be used instead of whatever format the host normally
+uses.  Normally GCC uses the same debug format as the host system.
+
+On MIPS based systems and on Alphas, you must specify whether you want
+GCC to create the normal ECOFF debugging format, or to use BSD-style
+stabs passed through the ECOFF symbol table.  The normal ECOFF debug
+format cannot fully handle languages other than C@.  BSD stabs format can
+handle other languages, but it only works with the GNU debugger GDB@.
+
+Normally, GCC uses the ECOFF debugging format by default; if you
+prefer BSD stabs, specify @option{--with-stabs} when you configure GCC@.
+
+No matter which default you choose when you configure GCC, the user
+can use the @option{-gcoff} and @option{-gstabs+} options to specify explicitly
+the debug format for a particular compilation.
+
+@option{--with-stabs} is meaningful on the ISC system on the 386, also, if
+@option{--with-gas} is used.  It selects use of stabs debugging
+information embedded in COFF output.  This kind of debugging information
+supports C++ well; ordinary COFF debugging information does not.
+
+@option{--with-stabs} is also meaningful on 386 systems running SVR4.  It
+selects use of stabs debugging information embedded in ELF output.  The
+C++ compiler currently (2.6.0) does not support the DWARF debugging
+information normally used on 386 SVR4 platforms; stabs provide a
+workable alternative.  This requires gas and gdb, as the normal SVR4
+tools can not generate or interpret stabs.
+
+@item --with-tls=@var{dialect}
+Specify the default TLS dialect, for systems were there is a choice.
+For ARM targets, possible values for @var{dialect} are @code{gnu} or
+@code{gnu2}, which select between the original GNU dialect and the GNU TLS
+descriptor-based dialect.
+
+@item --enable-multiarch
+Specify whether to enable or disable multiarch support.  The default is
+to check for glibc start files in a multiarch location, and enable it
+if the files are found.  The auto detection is enabled for native builds,
+and for cross builds configured with @option{--with-sysroot}, and without
+@option{--with-native-system-header-dir}.
+More documentation about multiarch can be found at
+@uref{http://wiki.debian.org/Multiarch}.
+
+@item --enable-vtable-verify
+Specify whether to enable or disable the vtable verification feature.
+Enabling this feature causes libstdc++ to be built with its virtual calls
+in verifiable mode.  This means that, when linked with libvtv, every
+virtual call in libstdc++ will verify the vtable pointer through which the
+call will be made before actually making the call.  If not linked with libvtv,
+the verifier will call stub functions (in libstdc++ itself) and do nothing.
+If vtable verification is disabled, then libstdc++ is not built with its
+virtual calls in verifiable mode at all.  However the libvtv library will
+still be built (see @option{--disable-libvtv} to turn off building libvtv).
+@option{--disable-vtable-verify} is the default.
+
+@item --disable-multilib
+Specify that multiple target
+libraries to support different target variants, calling
+conventions, etc.@: should not be built.  The default is to build a
+predefined set of them.
+
+Some targets provide finer-grained control over which multilibs are built
+(e.g., @option{--disable-softfloat}):
+@table @code
+@item arm-*-*
+fpu, 26bit, underscore, interwork, biendian, nofmult.
+
+@item m68*-*-*
+softfloat, m68881, m68000, m68020.
+
+@item mips*-*-*
+single-float, biendian, softfloat.
+
+@item powerpc*-*-*, rs6000*-*-*
+aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos, biendian,
+sysv, aix.
+
+@end table
+
+@item --with-multilib-list=@var{list}
+@itemx --without-multilib-list
+Specify what multilibs to build.
+Currently only implemented for sh*-*-* and x86-64-*-linux*.
+
+@table @code
+@item sh*-*-*
+@var{list} is a comma separated list of CPU names.  These must be of the
+form @code{sh*} or @code{m*} (in which case they match the compiler option
+for that processor).  The list should not contain any endian options -
+these are handled by @option{--with-endian}.
+
+If @var{list} is empty, then there will be no multilibs for extra
+processors.  The multilib for the secondary endian remains enabled.
+
+As a special case, if an entry in the list starts with a @code{!}
+(exclamation point), then it is added to the list of excluded multilibs.
+Entries of this sort should be compatible with @samp{MULTILIB_EXCLUDES}
+(once the leading @code{!} has been stripped).
+
+If @option{--with-multilib-list} is not given, then a default set of
+multilibs is selected based on the value of @option{--target}.  This is
+usually the complete set of libraries, but some targets imply a more
+specialized subset.
+
+Example 1: to configure a compiler for SH4A only, but supporting both
+endians, with little endian being the default:
+@smallexample
+--with-cpu=sh4a --with-endian=little,big --with-multilib-list=
+@end smallexample
+
+Example 2: to configure a compiler for both SH4A and SH4AL-DSP, but with
+only little endian SH4AL:
+@smallexample
+--with-cpu=sh4a --with-endian=little,big \
+--with-multilib-list=sh4al,!mb/m4al
+@end smallexample
+
+@item x86-64-*-linux*
+@var{list} is a comma separated list of @code{m32}, @code{m64} and
+@code{mx32} to enable 32-bit, 64-bit and x32 run-time libraries,
+respectively.  If @var{list} is empty, then there will be no multilibs
+and only the default run-time library will be enabled.
+
+If @option{--with-multilib-list} is not given, then only 32-bit and
+64-bit run-time libraries will be enabled.
+@end table
+
+@item --with-endian=@var{endians}
+Specify what endians to use.
+Currently only implemented for sh*-*-*.
+
+@var{endians} may be one of the following:
+@table @code
+@item big
+Use big endian exclusively.
+@item little
+Use little endian exclusively.
+@item big,little
+Use big endian by default.  Provide a multilib for little endian.
+@item little,big
+Use little endian by default.  Provide a multilib for big endian.
+@end table
+
+@item --enable-threads
+Specify that the target
+supports threads.  This affects the Objective-C compiler and runtime
+library, and exception handling for other languages like C++ and Java.
+On some systems, this is the default.
+
+In general, the best (and, in many cases, the only known) threading
+model available will be configured for use.  Beware that on some
+systems, GCC has not been taught what threading models are generally
+available for the system.  In this case, @option{--enable-threads} is an
+alias for @option{--enable-threads=single}.
+
+@item --disable-threads
+Specify that threading support should be disabled for the system.
+This is an alias for @option{--enable-threads=single}.
+
+@item --enable-threads=@var{lib}
+Specify that
+@var{lib} is the thread support library.  This affects the Objective-C
+compiler and runtime library, and exception handling for other languages
+like C++ and Java.  The possibilities for @var{lib} are:
+
+@table @code
+@item aix
+AIX thread support.
+@item dce
+DCE thread support.
+@item lynx
+LynxOS thread support.
+@item mipssde
+MIPS SDE thread support.
+@item no
+This is an alias for @samp{single}.
+@item posix
+Generic POSIX/Unix98 thread support.
+@item rtems
+RTEMS thread support.
+@item single
+Disable thread support, should work for all platforms.
+@item tpf
+TPF thread support.
+@item vxworks
+VxWorks thread support.
+@item win32
+Microsoft Win32 API thread support.
+@end table
+
+@item --enable-tls
+Specify that the target supports TLS (Thread Local Storage).  Usually
+configure can correctly determine if TLS is supported.  In cases where
+it guesses incorrectly, TLS can be explicitly enabled or disabled with
+@option{--enable-tls} or @option{--disable-tls}.  This can happen if
+the assembler supports TLS but the C library does not, or if the
+assumptions made by the configure test are incorrect.
+
+@item --disable-tls
+Specify that the target does not support TLS.
+This is an alias for @option{--enable-tls=no}.
+
+@item --with-cpu=@var{cpu}
+@itemx --with-cpu-32=@var{cpu}
+@itemx --with-cpu-64=@var{cpu}
+Specify which cpu variant the compiler should generate code for by default.
+@var{cpu} will be used as the default value of the @option{-mcpu=} switch.
+This option is only supported on some targets, including ARC, ARM, i386, M68k,
+PowerPC, and SPARC@.  It is mandatory for ARC@.  The @option{--with-cpu-32} and
+@option{--with-cpu-64} options specify separate default CPUs for
+32-bit and 64-bit modes; these options are only supported for i386,
+x86-64 and PowerPC.
+
+@item --with-schedule=@var{cpu}
+@itemx --with-arch=@var{cpu}
+@itemx --with-arch-32=@var{cpu}
+@itemx --with-arch-64=@var{cpu}
+@itemx --with-tune=@var{cpu}
+@itemx --with-tune-32=@var{cpu}
+@itemx --with-tune-64=@var{cpu}
+@itemx --with-abi=@var{abi}
+@itemx --with-fpu=@var{type}
+@itemx --with-float=@var{type}
+These configure options provide default values for the @option{-mschedule=},
+@option{-march=}, @option{-mtune=}, @option{-mabi=}, and @option{-mfpu=}
+options and for @option{-mhard-float} or @option{-msoft-float}.  As with
+@option{--with-cpu}, which switches will be accepted and acceptable values
+of the arguments depend on the target.
+
+@item --with-mode=@var{mode}
+Specify if the compiler should default to @option{-marm} or @option{-mthumb}.
+This option is only supported on ARM targets.
+
+@item --with-stack-offset=@var{num}
+This option sets the default for the -mstack-offset=@var{num} option,
+and will thus generally also control the setting of this option for
+libraries.  This option is only supported on Epiphany targets.
+
+@item --with-fpmath=@var{isa}
+This options sets @option{-mfpmath=sse} by default and specifies the default
+ISA for floating-point arithmetics.  You can select either @samp{sse} which
+enables @option{-msse2} or @samp{avx} which enables @option{-mavx} by default.
+This option is only supported on i386 and x86-64 targets.
+
+@item --with-nan=@var{encoding}
+On MIPS targets, set the default encoding convention to use for the
+special not-a-number (NaN) IEEE 754 floating-point data.  The
+possibilities for @var{encoding} are:
+@table @code
+@item legacy
+Use the legacy encoding, as with the @option{-mnan=legacy} command-line
+option.
+@item 2008
+Use the 754-2008 encoding, as with the @option{-mnan=2008} command-line
+option.
+@end table
+To use this configuration option you must have an assembler version
+installed that supports the @option{-mnan=} command-line option too.
+In the absence of this configuration option the default convention is
+the legacy encoding, as when neither of the @option{-mnan=2008} and
+@option{-mnan=legacy} command-line options has been used.
+
+@item --with-divide=@var{type}
+Specify how the compiler should generate code for checking for
+division by zero.  This option is only supported on the MIPS target.
+The possibilities for @var{type} are:
+@table @code
+@item traps
+Division by zero checks use conditional traps (this is the default on
+systems that support conditional traps).
+@item breaks
+Division by zero checks use the break instruction.
+@end table
+
+@c If you make --with-llsc the default for additional targets,
+@c update the --with-llsc description in the MIPS section below.
+
+@item --with-llsc
+On MIPS targets, make @option{-mllsc} the default when no
+@option{-mno-llsc} option is passed.  This is the default for
+Linux-based targets, as the kernel will emulate them if the ISA does
+not provide them.
+
+@item --without-llsc
+On MIPS targets, make @option{-mno-llsc} the default when no
+@option{-mllsc} option is passed.
+
+@item --with-synci
+On MIPS targets, make @option{-msynci} the default when no
+@option{-mno-synci} option is passed.
+
+@item --without-synci
+On MIPS targets, make @option{-mno-synci} the default when no
+@option{-msynci} option is passed.  This is the default.
+
+@item --with-mips-plt
+On MIPS targets, make use of copy relocations and PLTs.
+These features are extensions to the traditional
+SVR4-based MIPS ABIs and require support from GNU binutils
+and the runtime C library.
+
+@item --enable-__cxa_atexit
+Define if you want to use __cxa_atexit, rather than atexit, to
+register C++ destructors for local statics and global objects.
+This is essential for fully standards-compliant handling of
+destructors, but requires __cxa_atexit in libc.  This option is currently
+only available on systems with GNU libc.  When enabled, this will cause
+@option{-fuse-cxa-atexit} to be passed by default.
+
+@item --enable-gnu-indirect-function
+Define if you want to enable the @code{ifunc} attribute.  This option is
+currently only available on systems with GNU libc on certain targets.
+
+@item --enable-target-optspace
+Specify that target
+libraries should be optimized for code space instead of code speed.
+This is the default for the m32r platform.
+
+@item --with-cpp-install-dir=@var{dirname}
+Specify that the user visible @command{cpp} program should be installed
+in @file{@var{prefix}/@var{dirname}/cpp}, in addition to @var{bindir}.
+
+@item --enable-comdat
+Enable COMDAT group support.  This is primarily used to override the
+automatically detected value.
+
+@item --enable-initfini-array
+Force the use of sections @code{.init_array} and @code{.fini_array}
+(instead of @code{.init} and @code{.fini}) for constructors and
+destructors.  Option @option{--disable-initfini-array} has the
+opposite effect.  If neither option is specified, the configure script
+will try to guess whether the @code{.init_array} and
+@code{.fini_array} sections are supported and, if they are, use them.
+
+@item --enable-link-mutex
+When building GCC, use a mutex to avoid linking the compilers for
+multiple languages at the same time, to avoid thrashing on build
+systems with limited free memory.  The default is not to use such a mutex.
+
+@item --enable-maintainer-mode
+The build rules that regenerate the Autoconf and Automake output files as
+well as the GCC master message catalog @file{gcc.pot} are normally
+disabled.  This is because it can only be rebuilt if the complete source
+tree is present.  If you have changed the sources and want to rebuild the
+catalog, configuring with @option{--enable-maintainer-mode} will enable
+this.  Note that you need a recent version of the @code{gettext} tools
+to do so.
+
+@item --disable-bootstrap
+For a native build, the default configuration is to perform
+a 3-stage bootstrap of the compiler when @samp{make} is invoked,
+testing that GCC can compile itself correctly.  If you want to disable
+this process, you can configure with @option{--disable-bootstrap}.
+
+@item --enable-bootstrap
+In special cases, you may want to perform a 3-stage build
+even if the target and host triplets are different.
+This is possible when the host can run code compiled for
+the target (e.g.@: host is i686-linux, target is i486-linux).
+Starting from GCC 4.2, to do this you have to configure explicitly
+with @option{--enable-bootstrap}.
+
+@item --enable-generated-files-in-srcdir
+Neither the .c and .h files that are generated from Bison and flex nor the
+info manuals and man pages that are built from the .texi files are present
+in the SVN development tree.  When building GCC from that development tree,
+or from one of our snapshots, those generated files are placed in your
+build directory, which allows for the source to be in a readonly
+directory.
+
+If you configure with @option{--enable-generated-files-in-srcdir} then those
+generated files will go into the source directory.  This is mainly intended
+for generating release or prerelease tarballs of the GCC sources, since it
+is not a requirement that the users of source releases to have flex, Bison,
+or makeinfo.
+
+@item --enable-version-specific-runtime-libs
+Specify
+that runtime libraries should be installed in the compiler specific
+subdirectory (@file{@var{libdir}/gcc}) rather than the usual places.  In
+addition, @samp{libstdc++}'s include files will be installed into
+@file{@var{libdir}} unless you overruled it by using
+@option{--with-gxx-include-dir=@var{dirname}}.  Using this option is
+particularly useful if you intend to use several versions of GCC in
+parallel.  This is currently supported by @samp{libgfortran},
+@samp{libjava}, @samp{libstdc++}, and @samp{libobjc}.
+
+@item --enable-languages=@var{lang1},@var{lang2},@dots{}
+Specify that only a particular subset of compilers and
+their runtime libraries should be built.  For a list of valid values for
+@var{langN} you can issue the following command in the
+@file{gcc} directory of your GCC source tree:@*
+@smallexample
+grep language= */config-lang.in
+@end smallexample
+Currently, you can use any of the following:
+@code{all}, @code{ada}, @code{c}, @code{c++}, @code{fortran},
+@code{go}, @code{java}, @code{objc}, @code{obj-c++}.
+Building the Ada compiler has special requirements, see below.
+If you do not pass this flag, or specify the option @code{all}, then all
+default languages available in the @file{gcc} sub-tree will be configured.
+Ada, Go and Objective-C++ are not default languages; the rest are.
+
+@item --enable-stage1-languages=@var{lang1},@var{lang2},@dots{}
+Specify that a particular subset of compilers and their runtime
+libraries should be built with the system C compiler during stage 1 of
+the bootstrap process, rather than only in later stages with the
+bootstrapped C compiler.  The list of valid values is the same as for
+@option{--enable-languages}, and the option @code{all} will select all
+of the languages enabled by @option{--enable-languages}.  This option is
+primarily useful for GCC development; for instance, when a development
+version of the compiler cannot bootstrap due to compiler bugs, or when
+one is debugging front ends other than the C front end.  When this
+option is used, one can then build the target libraries for the
+specified languages with the stage-1 compiler by using @command{make
+stage1-bubble all-target}, or run the testsuite on the stage-1 compiler
+for the specified languages using @command{make stage1-start check-gcc}.
+
+@item --disable-libada
+Specify that the run-time libraries and tools used by GNAT should not
+be built.  This can be useful for debugging, or for compatibility with
+previous Ada build procedures, when it was required to explicitly
+do a @samp{make -C gcc gnatlib_and_tools}.
+
+@item --disable-libssp
+Specify that the run-time libraries for stack smashing protection
+should not be built.
+
+@item --disable-libquadmath
+Specify that the GCC quad-precision math library should not be built.
+On some systems, the library is required to be linkable when building
+the Fortran front end, unless @option{--disable-libquadmath-support}
+is used.
+
+@item --disable-libquadmath-support
+Specify that the Fortran front end and @code{libgfortran} do not add
+support for @code{libquadmath} on systems supporting it.
+
+@item --disable-libgomp
+Specify that the run-time libraries used by GOMP should not be built.
+
+@item --disable-libvtv
+Specify that the run-time libraries used by vtable verification
+should not be built.
+
+@item --with-dwarf2
+Specify that the compiler should
+use DWARF 2 debugging information as the default.
+
+@item --enable-targets=all
+@itemx --enable-targets=@var{target_list}
+Some GCC targets, e.g.@: powerpc64-linux, build bi-arch compilers.
+These are compilers that are able to generate either 64-bit or 32-bit
+code.  Typically, the corresponding 32-bit target, e.g.@:
+powerpc-linux for powerpc64-linux, only generates 32-bit code.  This
+option enables the 32-bit target to be a bi-arch compiler, which is
+useful when you want a bi-arch compiler that defaults to 32-bit, and
+you are building a bi-arch or multi-arch binutils in a combined tree.
+On mips-linux, this will build a tri-arch compiler (ABI o32/n32/64),
+defaulted to o32.
+Currently, this option only affects sparc-linux, powerpc-linux, x86-linux,
+mips-linux and s390-linux.
+
+@item --enable-secureplt
+This option enables @option{-msecure-plt} by default for powerpc-linux.
+@ifnothtml
+@xref{RS/6000 and PowerPC Options,, RS/6000 and PowerPC Options, gcc,
+Using the GNU Compiler Collection (GCC)},
+@end ifnothtml
+@ifhtml
+See ``RS/6000 and PowerPC Options'' in the main manual
+@end ifhtml
+
+@item --enable-cld
+This option enables @option{-mcld} by default for 32-bit x86 targets.
+@ifnothtml
+@xref{i386 and x86-64 Options,, i386 and x86-64 Options, gcc,
+Using the GNU Compiler Collection (GCC)},
+@end ifnothtml
+@ifhtml
+See ``i386 and x86-64 Options'' in the main manual
+@end ifhtml
+
+@item --enable-win32-registry
+@itemx --enable-win32-registry=@var{key}
+@itemx --disable-win32-registry
+The @option{--enable-win32-registry} option enables Microsoft Windows-hosted GCC
+to look up installations paths in the registry using the following key:
+
+@smallexample
+@code{HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\@var{key}}
+@end smallexample
+
+@var{key} defaults to GCC version number, and can be overridden by the
+@option{--enable-win32-registry=@var{key}} option.  Vendors and distributors
+who use custom installers are encouraged to provide a different key,
+perhaps one comprised of vendor name and GCC version number, to
+avoid conflict with existing installations.  This feature is enabled
+by default, and can be disabled by @option{--disable-win32-registry}
+option.  This option has no effect on the other hosts.
+
+@item --nfp
+Specify that the machine does not have a floating point unit.  This
+option only applies to @samp{m68k-sun-sunos@var{n}}.  On any other
+system, @option{--nfp} has no effect.
+
+@item --enable-werror
+@itemx --disable-werror
+@itemx --enable-werror=yes
+@itemx --enable-werror=no
+When you specify this option, it controls whether certain files in the
+compiler are built with @option{-Werror} in bootstrap stage2 and later.
+If you don't specify it, @option{-Werror} is turned on for the main
+development trunk.  However it defaults to off for release branches and
+final releases.  The specific files which get @option{-Werror} are
+controlled by the Makefiles.
+
+@item --enable-checking
+@itemx --enable-checking=@var{list}
+When you specify this option, the compiler is built to perform internal
+consistency checks of the requested complexity.  This does not change the
+generated code, but adds error checking within the compiler.  This will
+slow down the compiler and may only work properly if you are building
+the compiler with GCC@.  This is @samp{yes} by default when building
+from SVN or snapshots, but @samp{release} for releases.  The default
+for building the stage1 compiler is @samp{yes}.  More control
+over the checks may be had by specifying @var{list}.  The categories of
+checks available are @samp{yes} (most common checks
+@samp{assert,misc,tree,gc,rtlflag,runtime}), @samp{no} (no checks at
+all), @samp{all} (all but @samp{valgrind}), @samp{release} (cheapest
+checks @samp{assert,runtime}) or @samp{none} (same as @samp{no}).
+Individual checks can be enabled with these flags @samp{assert},
+@samp{df}, @samp{fold}, @samp{gc}, @samp{gcac} @samp{misc}, @samp{rtl},
+@samp{rtlflag}, @samp{runtime}, @samp{tree}, and @samp{valgrind}.
+
+The @samp{valgrind} check requires the external @command{valgrind}
+simulator, available from @uref{http://valgrind.org/}.  The
+@samp{df}, @samp{rtl}, @samp{gcac} and @samp{valgrind} checks are very expensive.
+To disable all checking, @samp{--disable-checking} or
+@samp{--enable-checking=none} must be explicitly requested.  Disabling
+assertions will make the compiler and runtime slightly faster but
+increase the risk of undetected internal errors causing wrong code to be
+generated.
+
+@item --disable-stage1-checking
+@itemx --enable-stage1-checking
+@itemx --enable-stage1-checking=@var{list}
+If no @option{--enable-checking} option is specified the stage1
+compiler will be built with @samp{yes} checking enabled, otherwise
+the stage1 checking flags are the same as specified by
+@option{--enable-checking}.  To build the stage1 compiler with
+different checking options use @option{--enable-stage1-checking}.
+The list of checking options is the same as for @option{--enable-checking}.
+If your system is too slow or too small to bootstrap a released compiler
+with checking for stage1 enabled, you can use @samp{--disable-stage1-checking}
+to disable checking for the stage1 compiler.
+
+@item --enable-coverage
+@itemx --enable-coverage=@var{level}
+With this option, the compiler is built to collect self coverage
+information, every time it is run.  This is for internal development
+purposes, and only works when the compiler is being built with gcc.  The
+@var{level} argument controls whether the compiler is built optimized or
+not, values are @samp{opt} and @samp{noopt}.  For coverage analysis you
+want to disable optimization, for performance analysis you want to
+enable optimization.  When coverage is enabled, the default level is
+without optimization.
+
+@item --enable-gather-detailed-mem-stats
+When this option is specified more detailed information on memory
+allocation is gathered.  This information is printed when using
+@option{-fmem-report}.
+
+@item --enable-nls
+@itemx --disable-nls
+The @option{--enable-nls} option enables Native Language Support (NLS),
+which lets GCC output diagnostics in languages other than American
+English.  Native Language Support is enabled by default if not doing a
+canadian cross build.  The @option{--disable-nls} option disables NLS@.
+
+@item --with-included-gettext
+If NLS is enabled, the @option{--with-included-gettext} option causes the build
+procedure to prefer its copy of GNU @command{gettext}.
+
+@item --with-catgets
+If NLS is enabled, and if the host lacks @code{gettext} but has the
+inferior @code{catgets} interface, the GCC build procedure normally
+ignores @code{catgets} and instead uses GCC's copy of the GNU
+@code{gettext} library.  The @option{--with-catgets} option causes the
+build procedure to use the host's @code{catgets} in this situation.
+
+@item --with-libiconv-prefix=@var{dir}
+Search for libiconv header files in @file{@var{dir}/include} and
+libiconv library files in @file{@var{dir}/lib}.
+
+@item --enable-obsolete
+Enable configuration for an obsoleted system.  If you attempt to
+configure GCC for a system (build, host, or target) which has been
+obsoleted, and you do not specify this flag, configure will halt with an
+error message.
+
+All support for systems which have been obsoleted in one release of GCC
+is removed entirely in the next major release, unless someone steps
+forward to maintain the port.
+
+@item --enable-decimal-float
+@itemx --enable-decimal-float=yes
+@itemx --enable-decimal-float=no
+@itemx --enable-decimal-float=bid
+@itemx --enable-decimal-float=dpd
+@itemx --disable-decimal-float
+Enable (or disable) support for the C decimal floating point extension
+that is in the IEEE 754-2008 standard.  This is enabled by default only
+on PowerPC, i386, and x86_64 GNU/Linux systems.  Other systems may also
+support it, but require the user to specifically enable it.  You can
+optionally control which decimal floating point format is used (either
+@samp{bid} or @samp{dpd}).  The @samp{bid} (binary integer decimal)
+format is default on i386 and x86_64 systems, and the @samp{dpd}
+(densely packed decimal) format is default on PowerPC systems.
+
+@item --enable-fixed-point
+@itemx --disable-fixed-point
+Enable (or disable) support for C fixed-point arithmetic.
+This option is enabled by default for some targets (such as MIPS) which
+have hardware-support for fixed-point operations.  On other targets, you
+may enable this option manually.
+
+@item --with-long-double-128
+Specify if @code{long double} type should be 128-bit by default on selected
+GNU/Linux architectures.  If using @code{--without-long-double-128},
+@code{long double} will be by default 64-bit, the same as @code{double} type.
+When neither of these configure options are used, the default will be
+128-bit @code{long double} when built against GNU C Library 2.4 and later,
+64-bit @code{long double} otherwise.
+
+@item --with-gmp=@var{pathname}
+@itemx --with-gmp-include=@var{pathname}
+@itemx --with-gmp-lib=@var{pathname}
+@itemx --with-mpfr=@var{pathname}
+@itemx --with-mpfr-include=@var{pathname}
+@itemx --with-mpfr-lib=@var{pathname}
+@itemx --with-mpc=@var{pathname}
+@itemx --with-mpc-include=@var{pathname}
+@itemx --with-mpc-lib=@var{pathname}
+If you want to build GCC but do not have the GMP library, the MPFR
+library and/or the MPC library installed in a standard location and
+do not have their sources present in the GCC source tree then you
+can explicitly specify the directory where they are installed
+(@samp{--with-gmp=@var{gmpinstalldir}},
+@samp{--with-mpfr=@/@var{mpfrinstalldir}},
+@samp{--with-mpc=@/@var{mpcinstalldir}}).  The
+@option{--with-gmp=@/@var{gmpinstalldir}} option is shorthand for
+@option{--with-gmp-lib=@/@var{gmpinstalldir}/lib} and
+@option{--with-gmp-include=@/@var{gmpinstalldir}/include}.  Likewise the
+@option{--with-mpfr=@/@var{mpfrinstalldir}} option is shorthand for
+@option{--with-mpfr-lib=@/@var{mpfrinstalldir}/lib} and
+@option{--with-mpfr-include=@/@var{mpfrinstalldir}/include}, also the
+@option{--with-mpc=@/@var{mpcinstalldir}} option is shorthand for
+@option{--with-mpc-lib=@/@var{mpcinstalldir}/lib} and
+@option{--with-mpc-include=@/@var{mpcinstalldir}/include}.  If these
+shorthand assumptions are not correct, you can use the explicit
+include and lib options directly.  You might also need to ensure the
+shared libraries can be found by the dynamic linker when building and
+using GCC, for example by setting the runtime shared library path
+variable (@env{LD_LIBRARY_PATH} on GNU/Linux and Solaris systems).
+
+These flags are applicable to the host platform only.  When building
+a cross compiler, they will not be used to configure target libraries.
+
+@item --with-isl=@var{pathname}
+@itemx --with-isl-include=@var{pathname}
+@itemx --with-isl-lib=@var{pathname}
+@itemx --with-cloog=@var{pathname}
+@itemx --with-cloog-include=@var{pathname}
+@itemx --with-cloog-lib=@var{pathname}
+If you do not have ISL and the CLooG
+libraries installed in a standard location and you want to build GCC,
+you can explicitly specify the directory where they are installed
+(@samp{--with-isl=@/@var{islinstalldir}},
+@samp{--with-cloog=@/@var{clooginstalldir}}). The
+@option{--with-isl=@/@var{islinstalldir}} option is shorthand for
+@option{--with-isl-lib=@/@var{islinstalldir}/lib} and
+@option{--with-isl-include=@/@var{islinstalldir}/include}.  Likewise the
+@option{--with-cloog=@/@var{clooginstalldir}} option is shorthand for
+@option{--with-cloog-lib=@/@var{clooginstalldir}/lib} and
+@option{--with-cloog-include=@/@var{clooginstalldir}/include}.  If these
+shorthand assumptions are not correct, you can use the explicit
+include and lib options directly.
+
+These flags are applicable to the host platform only.  When building
+a cross compiler, they will not be used to configure target libraries.
+
+@item --with-host-libstdcxx=@var{linker-args}
+If you are linking with a static copy of PPL, you can use this option
+to specify how the linker should find the standard C++ library used
+internally by PPL.  Typical values of @var{linker-args} might be
+@samp{-lstdc++} or @samp{-Wl,-Bstatic,-lstdc++,-Bdynamic -lm}.  If you are
+linking with a shared copy of PPL, you probably do not need this
+option; shared library dependencies will cause the linker to search
+for the standard C++ library automatically.
+
+@item --with-stage1-ldflags=@var{flags}
+This option may be used to set linker flags to be used when linking
+stage 1 of GCC.  These are also used when linking GCC if configured with
+@option{--disable-bootstrap}.  By default no special flags are used.
+
+@item --with-stage1-libs=@var{libs}
+This option may be used to set libraries to be used when linking stage 1
+of GCC.  These are also used when linking GCC if configured with
+@option{--disable-bootstrap}.  The default is the argument to
+@option{--with-host-libstdcxx}, if specified.
+
+@item --with-boot-ldflags=@var{flags}
+This option may be used to set linker flags to be used when linking
+stage 2 and later when bootstrapping GCC.  If neither --with-boot-libs
+nor --with-host-libstdcxx is set to a value, then the default is
+@samp{-static-libstdc++ -static-libgcc}.
+
+@item --with-boot-libs=@var{libs}
+This option may be used to set libraries to be used when linking stage 2
+and later when bootstrapping GCC.  The default is the argument to
+@option{--with-host-libstdcxx}, if specified.
+
+@item --with-debug-prefix-map=@var{map}
+Convert source directory names using @option{-fdebug-prefix-map} when
+building runtime libraries.  @samp{@var{map}} is a space-separated
+list of maps of the form @samp{@var{old}=@var{new}}.
+
+@item --enable-linker-build-id
+Tells GCC to pass @option{--build-id} option to the linker for all final
+links (links performed without the @option{-r} or @option{--relocatable}
+option), if the linker supports it.  If you specify
+@option{--enable-linker-build-id}, but your linker does not
+support @option{--build-id} option, a warning is issued and the
+@option{--enable-linker-build-id} option is ignored.  The default is off.
+
+@item --with-linker-hash-style=@var{choice}
+Tells GCC to pass @option{--hash-style=@var{choice}} option to the
+linker for all final links. @var{choice} can be one of
+@samp{sysv}, @samp{gnu}, and @samp{both} where @samp{sysv} is the default.
+
+@item --enable-gnu-unique-object
+@itemx --disable-gnu-unique-object
+Tells GCC to use the gnu_unique_object relocation for C++ template
+static data members and inline function local statics.  Enabled by
+default for a toolchain with an assembler that accepts it and
+GLIBC 2.11 or above, otherwise disabled.
+
+@item --enable-lto
+@itemx --disable-lto
+Enable support for link-time optimization (LTO).  This is enabled by
+default, and may be disabled using @option{--disable-lto}.
+
+@item --with-plugin-ld=@var{pathname}
+Enable an alternate linker to be used at link-time optimization (LTO)
+link time when @option{-fuse-linker-plugin} is enabled.
+This linker should have plugin support such as gold starting with
+version 2.20 or GNU ld starting with version 2.21.
+See @option{-fuse-linker-plugin} for details.
+
+@item --enable-canonical-system-headers
+@itemx --disable-canonical-system-headers
+Enable system header path canonicalization for @file{libcpp}.  This can
+produce shorter header file paths in diagnostics and dependency output
+files, but these changed header paths may conflict with some compilation
+environments.  Enabled by default, and may be disabled using
+@option{--disable-canonical-system-headers}.
+
+@item --with-glibc-version=@var{major}.@var{minor}
+Tell GCC that when the GNU C Library (glibc) is used on the target it
+will be version @var{major}.@var{minor} or later.  Normally this can
+be detected from the C library's header files, but this option may be
+needed when bootstrapping a cross toolchain without the header files
+available for building the initial bootstrap compiler.
+
+If GCC is configured with some multilibs that use glibc and some that
+do not, this option applies only to the multilibs that use glibc.
+However, such configurations may not work well as not all the relevant
+configuration in GCC is on a per-multilib basis.
+@end table
+
+@subheading Cross-Compiler-Specific Options
+The following options only apply to building cross compilers.
+
+@table @code
+@item --with-sysroot
+@itemx --with-sysroot=@var{dir}
+Tells GCC to consider @var{dir} as the root of a tree that contains
+(a subset of) the root filesystem of the target operating system.
+Target system headers, libraries and run-time object files will be
+searched for in there.  More specifically, this acts as if
+@option{--sysroot=@var{dir}} was added to the default options of the built
+compiler.  The specified directory is not copied into the
+install tree, unlike the options @option{--with-headers} and
+@option{--with-libs} that this option obsoletes.  The default value,
+in case @option{--with-sysroot} is not given an argument, is
+@option{$@{gcc_tooldir@}/sys-root}.  If the specified directory is a
+subdirectory of @option{$@{exec_prefix@}}, then it will be found relative to
+the GCC binaries if the installation tree is moved.
+
+This option affects the system root for the compiler used to build
+target libraries (which runs on the build system) and the compiler newly
+installed with @code{make install}; it does not affect the compiler which is
+used to build GCC itself.
+
+If you specify the @option{--with-native-system-header-dir=@var{dirname}}
+option then the compiler will search that directory within @var{dirname} for
+native system headers rather than the default @file{/usr/include}.
+
+@item --with-build-sysroot
+@itemx --with-build-sysroot=@var{dir}
+Tells GCC to consider @var{dir} as the system root (see
+@option{--with-sysroot}) while building target libraries, instead of
+the directory specified with @option{--with-sysroot}.  This option is
+only useful when you are already using @option{--with-sysroot}.  You
+can use @option{--with-build-sysroot} when you are configuring with
+@option{--prefix} set to a directory that is different from the one in
+which you are installing GCC and your target libraries.
+
+This option affects the system root for the compiler used to build
+target libraries (which runs on the build system); it does not affect
+the compiler which is used to build GCC itself.
+
+If you specify the @option{--with-native-system-header-dir=@var{dirname}}
+option then the compiler will search that directory within @var{dirname} for
+native system headers rather than the default @file{/usr/include}.
+
+@item --with-headers
+@itemx --with-headers=@var{dir}
+Deprecated in favor of @option{--with-sysroot}.
+Specifies that target headers are available when building a cross compiler.
+The @var{dir} argument specifies a directory which has the target include
+files.  These include files will be copied into the @file{gcc} install
+directory.  @emph{This option with the @var{dir} argument is required} when
+building a cross compiler, if @file{@var{prefix}/@var{target}/sys-include}
+doesn't pre-exist.  If @file{@var{prefix}/@var{target}/sys-include} does
+pre-exist, the @var{dir} argument may be omitted.  @command{fixincludes}
+will be run on these files to make them compatible with GCC@.
+
+@item --without-headers
+Tells GCC not use any target headers from a libc when building a cross
+compiler.  When crossing to GNU/Linux, you need the headers so GCC
+can build the exception handling for libgcc.
+
+@item --with-libs
+@itemx --with-libs="@var{dir1} @var{dir2} @dots{} @var{dirN}"
+Deprecated in favor of @option{--with-sysroot}.
+Specifies a list of directories which contain the target runtime
+libraries.  These libraries will be copied into the @file{gcc} install
+directory.  If the directory list is omitted, this option has no
+effect.
+
+@item --with-newlib
+Specifies that @samp{newlib} is
+being used as the target C library.  This causes @code{__eprintf} to be
+omitted from @file{libgcc.a} on the assumption that it will be provided by
+@samp{newlib}.
+
+@item --with-avrlibc
+Specifies that @samp{AVR-Libc} is
+being used as the target C library.  This causes float support
+functions like @code{__addsf3} to be omitted from @file{libgcc.a} on
+the assumption that it will be provided by @file{libm.a}.  For more
+technical details, cf. @uref{http://gcc.gnu.org/PR54461,,PR54461}.
+This option is only supported for the AVR target.  It is not supported for
+RTEMS configurations, which currently use newlib.  The option is
+supported since version 4.7.2 and is the default in 4.8.0 and newer.
+
+@item --with-nds32-lib=@var{library}
+Specifies that @var{library} setting is used for building @file{libgcc.a}.
+Currently, the valid @var{library} is @samp{newlib} or @samp{mculib}.
+This option is only supported for the NDS32 target.
+
+@item --with-build-time-tools=@var{dir}
+Specifies where to find the set of target tools (assembler, linker, etc.)
+that will be used while building GCC itself.  This option can be useful
+if the directory layouts are different between the system you are building
+GCC on, and the system where you will deploy it.
+
+For example, on an @samp{ia64-hp-hpux} system, you may have the GNU
+assembler and linker in @file{/usr/bin}, and the native tools in a
+different path, and build a toolchain that expects to find the
+native tools in @file{/usr/bin}.
+
+When you use this option, you should ensure that @var{dir} includes
+@command{ar}, @command{as}, @command{ld}, @command{nm},
+@command{ranlib} and @command{strip} if necessary, and possibly
+@command{objdump}.  Otherwise, GCC may use an inconsistent set of
+tools.
+@end table
+
+@subheading Java-Specific Options
+
+The following option applies to the build of the Java front end.
+
+@table @code
+@item --disable-libgcj
+Specify that the run-time libraries
+used by GCJ should not be built.  This is useful in case you intend
+to use GCJ with some other run-time, or you're going to install it
+separately, or it just happens not to build on your particular
+machine.  In general, if the Java front end is enabled, the GCJ
+libraries will be enabled too, unless they're known to not work on
+the target platform.  If GCJ is enabled but @samp{libgcj} isn't built, you
+may need to port it; in this case, before modifying the top-level
+@file{configure.in} so that @samp{libgcj} is enabled by default on this platform,
+you may use @option{--enable-libgcj} to override the default.
+
+@end table
+
+The following options apply to building @samp{libgcj}.
+
+@subsubheading General Options
+
+@table @code
+@item --enable-java-maintainer-mode
+By default the @samp{libjava} build will not attempt to compile the
+@file{.java} source files to @file{.class}.  Instead, it will use the
+@file{.class} files from the source tree.  If you use this option you
+must have executables named @command{ecj1} and @command{gjavah} in your path
+for use by the build.  You must use this option if you intend to
+modify any @file{.java} files in @file{libjava}.
+
+@item --with-java-home=@var{dirname}
+This @samp{libjava} option overrides the default value of the
+@samp{java.home} system property.  It is also used to set
+@samp{sun.boot.class.path} to @file{@var{dirname}/lib/rt.jar}.  By
+default @samp{java.home} is set to @file{@var{prefix}} and
+@samp{sun.boot.class.path} to
+@file{@var{datadir}/java/libgcj-@var{version}.jar}.
+
+@item --with-ecj-jar=@var{filename}
+This option can be used to specify the location of an external jar
+file containing the Eclipse Java compiler.  A specially modified
+version of this compiler is used by @command{gcj} to parse
+@file{.java} source files.  If this option is given, the
+@samp{libjava} build will create and install an @file{ecj1} executable
+which uses this jar file at runtime.
+
+If this option is not given, but an @file{ecj.jar} file is found in
+the topmost source tree at configure time, then the @samp{libgcj}
+build will create and install @file{ecj1}, and will also install the
+discovered @file{ecj.jar} into a suitable place in the install tree.
+
+If @file{ecj1} is not installed, then the user will have to supply one
+on his path in order for @command{gcj} to properly parse @file{.java}
+source files.  A suitable jar is available from
+@uref{ftp://sourceware.org/pub/java/}.
+
+@item --disable-getenv-properties
+Don't set system properties from @env{GCJ_PROPERTIES}.
+
+@item --enable-hash-synchronization
+Use a global hash table for monitor locks.  Ordinarily,
+@samp{libgcj}'s @samp{configure} script automatically makes
+the correct choice for this option for your platform.  Only use
+this if you know you need the library to be configured differently.
+
+@item --enable-interpreter
+Enable the Java interpreter.  The interpreter is automatically
+enabled by default on all platforms that support it.  This option
+is really only useful if you want to disable the interpreter
+(using @option{--disable-interpreter}).
+
+@item --disable-java-net
+Disable java.net.  This disables the native part of java.net only,
+using non-functional stubs for native method implementations.
+
+@item --disable-jvmpi
+Disable JVMPI support.
+
+@item --disable-libgcj-bc
+Disable BC ABI compilation of certain parts of libgcj.  By default,
+some portions of libgcj are compiled with @option{-findirect-dispatch}
+and @option{-fno-indirect-classes}, allowing them to be overridden at
+run-time.
+
+If @option{--disable-libgcj-bc} is specified, libgcj is built without
+these options.  This allows the compile-time linker to resolve
+dependencies when statically linking to libgcj.  However it makes it
+impossible to override the affected portions of libgcj at run-time.
+
+@item --enable-reduced-reflection
+Build most of libgcj with @option{-freduced-reflection}.  This reduces
+the size of libgcj at the expense of not being able to do accurate
+reflection on the classes it contains.  This option is safe if you
+know that code using libgcj will never use reflection on the standard
+runtime classes in libgcj (including using serialization, RMI or CORBA).
+
+@item --with-ecos
+Enable runtime eCos target support.
+
+@item --without-libffi
+Don't use @samp{libffi}.  This will disable the interpreter and JNI
+support as well, as these require @samp{libffi} to work.
+
+@item --enable-libgcj-debug
+Enable runtime debugging code.
+
+@item --enable-libgcj-multifile
+If specified, causes all @file{.java} source files to be
+compiled into @file{.class} files in one invocation of
+@samp{gcj}.  This can speed up build time, but is more
+resource-intensive.  If this option is unspecified or
+disabled, @samp{gcj} is invoked once for each @file{.java}
+file to compile into a @file{.class} file.
+
+@item --with-libiconv-prefix=DIR
+Search for libiconv in @file{DIR/include} and @file{DIR/lib}.
+
+@item --enable-sjlj-exceptions
+Force use of the @code{setjmp}/@code{longjmp}-based scheme for exceptions.
+@samp{configure} ordinarily picks the correct value based on the platform.
+Only use this option if you are sure you need a different setting.
+
+@item --with-system-zlib
+Use installed @samp{zlib} rather than that included with GCC@.
+
+@item --with-win32-nlsapi=ansi, unicows or unicode
+Indicates how MinGW @samp{libgcj} translates between UNICODE
+characters and the Win32 API@.
+
+@item --enable-java-home
+If enabled, this creates a JPackage compatible SDK environment during install.
+Note that if --enable-java-home is used, --with-arch-directory=ARCH must also
+be specified.
+
+@item --with-arch-directory=ARCH
+Specifies the name to use for the @file{jre/lib/ARCH} directory in the SDK
+environment created when --enable-java-home is passed. Typical names for this
+directory include i386, amd64, ia64, etc.
+
+@item --with-os-directory=DIR
+Specifies the OS directory for the SDK include directory. This is set to auto
+detect, and is typically 'linux'.
+
+@item --with-origin-name=NAME
+Specifies the JPackage origin name. This defaults to the 'gcj' in
+java-1.5.0-gcj.
+
+@item --with-arch-suffix=SUFFIX
+Specifies the suffix for the sdk directory. Defaults to the empty string.
+Examples include '.x86_64' in 'java-1.5.0-gcj-1.5.0.0.x86_64'.
+
+@item --with-jvm-root-dir=DIR
+Specifies where to install the SDK. Default is $(prefix)/lib/jvm.
+
+@item --with-jvm-jar-dir=DIR
+Specifies where to install jars. Default is $(prefix)/lib/jvm-exports.
+
+@item --with-python-dir=DIR
+Specifies where to install the Python modules used for aot-compile. DIR should
+not include the prefix used in installation. For example, if the Python modules
+are to be installed in /usr/lib/python2.5/site-packages, then
+--with-python-dir=/lib/python2.5/site-packages should be passed. If this is
+not specified, then the Python modules are installed in $(prefix)/share/python.
+
+@item --enable-aot-compile-rpm
+Adds aot-compile-rpm to the list of installed scripts.
+
+@item --enable-browser-plugin
+Build the gcjwebplugin web browser plugin.
+
+@item --enable-static-libjava
+Build static libraries in libjava. The default is to only build shared
+libraries.
+
+@table @code
+@item ansi
+Use the single-byte @code{char} and the Win32 A functions natively,
+translating to and from UNICODE when using these functions.  If
+unspecified, this is the default.
+
+@item unicows
+Use the @code{WCHAR} and Win32 W functions natively.  Adds
+@code{-lunicows} to @file{libgcj.spec} to link with @samp{libunicows}.
+@file{unicows.dll} needs to be deployed on Microsoft Windows 9X machines
+running built executables.  @file{libunicows.a}, an open-source
+import library around Microsoft's @code{unicows.dll}, is obtained from
+@uref{http://libunicows.sourceforge.net/}, which also gives details
+on getting @file{unicows.dll} from Microsoft.
+
+@item unicode
+Use the @code{WCHAR} and Win32 W functions natively.  Does @emph{not}
+add @code{-lunicows} to @file{libgcj.spec}.  The built executables will
+only run on Microsoft Windows NT and above.
+@end table
+@end table
+
+@subsubheading AWT-Specific Options
+
+@table @code
+@item --with-x
+Use the X Window System.
+
+@item --enable-java-awt=PEER(S)
+Specifies the AWT peer library or libraries to build alongside
+@samp{libgcj}.  If this option is unspecified or disabled, AWT
+will be non-functional.  Current valid values are @option{gtk} and
+@option{xlib}.  Multiple libraries should be separated by a
+comma (i.e.@: @option{--enable-java-awt=gtk,xlib}).
+
+@item --enable-gtk-cairo
+Build the cairo Graphics2D implementation on GTK@.
+
+@item --enable-java-gc=TYPE
+Choose garbage collector.  Defaults to @option{boehm} if unspecified.
+
+@item --disable-gtktest
+Do not try to compile and run a test GTK+ program.
+
+@item --disable-glibtest
+Do not try to compile and run a test GLIB program.
+
+@item --with-libart-prefix=PFX
+Prefix where libart is installed (optional).
+
+@item --with-libart-exec-prefix=PFX
+Exec prefix where libart is installed (optional).
+
+@item --disable-libarttest
+Do not try to compile and run a test libart program.
+
+@end table
+
+@subsubheading Overriding @command{configure} test results
+
+Sometimes, it might be necessary to override the result of some
+@command{configure} test, for example in order to ease porting to a new
+system or work around a bug in a test.  The toplevel @command{configure}
+script provides three variables for this:
+
+@table @code
+
+@item build_configargs
+@cindex @code{build_configargs}
+The contents of this variable is passed to all build @command{configure}
+scripts.
+
+@item host_configargs
+@cindex @code{host_configargs}
+The contents of this variable is passed to all host @command{configure}
+scripts.
+
+@item target_configargs
+@cindex @code{target_configargs}
+The contents of this variable is passed to all target @command{configure}
+scripts.
+
+@end table
+
+In order to avoid shell and @command{make} quoting issues for complex
+overrides, you can pass a setting for @env{CONFIG_SITE} and set
+variables in the site file.
+
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+
+@c ***Building****************************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Building, Testing, Configuration, Installing GCC
+@end ifnothtml
+@ifset buildhtml
+@ifnothtml
+@chapter Building
+@end ifnothtml
+@cindex Installing GCC: Building
+
+Now that GCC is configured, you are ready to build the compiler and
+runtime libraries.
+
+Some commands executed when making the compiler may fail (return a
+nonzero status) and be ignored by @command{make}.  These failures, which
+are often due to files that were not found, are expected, and can safely
+be ignored.
+
+It is normal to have compiler warnings when compiling certain files.
+Unless you are a GCC developer, you can generally ignore these warnings
+unless they cause compilation to fail.  Developers should attempt to fix
+any warnings encountered, however they can temporarily continue past
+warnings-as-errors by specifying the configure flag
+@option{--disable-werror}.
+
+On certain old systems, defining certain environment variables such as
+@env{CC} can interfere with the functioning of @command{make}.
+
+If you encounter seemingly strange errors when trying to build the
+compiler in a directory other than the source directory, it could be
+because you have previously configured the compiler in the source
+directory.  Make sure you have done all the necessary preparations.
+
+If you build GCC on a BSD system using a directory stored in an old System
+V file system, problems may occur in running @command{fixincludes} if the
+System V file system doesn't support symbolic links.  These problems
+result in a failure to fix the declaration of @code{size_t} in
+@file{sys/types.h}.  If you find that @code{size_t} is a signed type and
+that type mismatches occur, this could be the cause.
+
+The solution is not to use such a directory for building GCC@.
+
+Similarly, when building from SVN or snapshots, or if you modify
+@file{*.l} files, you need the Flex lexical analyzer generator
+installed.  If you do not modify @file{*.l} files, releases contain
+the Flex-generated files and you do not need Flex installed to build
+them.  There is still one Flex-based lexical analyzer (part of the
+build machinery, not of GCC itself) that is used even if you only
+build the C front end.
+
+When building from SVN or snapshots, or if you modify Texinfo
+documentation, you need version 4.7 or later of Texinfo installed if you
+want Info documentation to be regenerated.  Releases contain Info
+documentation pre-built for the unmodified documentation in the release.
+
+@section Building a native compiler
+
+For a native build, the default configuration is to perform
+a 3-stage bootstrap of the compiler when @samp{make} is invoked.
+This will build the entire GCC system and ensure that it compiles
+itself correctly.  It can be disabled with the @option{--disable-bootstrap}
+parameter to @samp{configure}, but bootstrapping is suggested because
+the compiler will be tested more completely and could also have
+better performance.
+
+The bootstrapping process will complete the following steps:
+
+@itemize @bullet
+@item
+Build tools necessary to build the compiler.
+
+@item
+Perform a 3-stage bootstrap of the compiler.  This includes building
+three times the target tools for use by the compiler such as binutils
+(bfd, binutils, gas, gprof, ld, and opcodes) if they have been
+individually linked or moved into the top level GCC source tree before
+configuring.
+
+@item
+Perform a comparison test of the stage2 and stage3 compilers.
+
+@item
+Build runtime libraries using the stage3 compiler from the previous step.
+
+@end itemize
+
+If you are short on disk space you might consider @samp{make
+bootstrap-lean} instead.  The sequence of compilation is the
+same described above, but object files from the stage1 and
+stage2 of the 3-stage bootstrap of the compiler are deleted as
+soon as they are no longer needed.
+
+If you wish to use non-default GCC flags when compiling the stage2
+and stage3 compilers, set @code{BOOT_CFLAGS} on the command line when
+doing @samp{make}.  For example, if you want to save additional space
+during the bootstrap and in the final installation as well, you can
+build the compiler binaries without debugging information as in the
+following example.  This will save roughly 40% of disk space both for
+the bootstrap and the final installation.  (Libraries will still contain
+debugging information.)
+
+@smallexample
+make BOOT_CFLAGS='-O' bootstrap
+@end smallexample
+
+You can place non-default optimization flags into @code{BOOT_CFLAGS}; they
+are less well tested here than the default of @samp{-g -O2}, but should
+still work.  In a few cases, you may find that you need to specify special
+flags such as @option{-msoft-float} here to complete the bootstrap; or,
+if the native compiler miscompiles the stage1 compiler, you may need
+to work around this, by choosing @code{BOOT_CFLAGS} to avoid the parts
+of the stage1 compiler that were miscompiled, or by using @samp{make
+bootstrap4} to increase the number of stages of bootstrap.
+
+@code{BOOT_CFLAGS} does not apply to bootstrapped target libraries.
+Since these are always compiled with the compiler currently being
+bootstrapped, you can use @code{CFLAGS_FOR_TARGET} to modify their
+compilation flags, as for non-bootstrapped target libraries.
+Again, if the native compiler miscompiles the stage1 compiler, you may
+need to work around this by avoiding non-working parts of the stage1
+compiler.  Use @code{STAGE1_TFLAGS} to this end.
+
+If you used the flag @option{--enable-languages=@dots{}} to restrict
+the compilers to be built, only those you've actually enabled will be
+built.  This will of course only build those runtime libraries, for
+which the particular compiler has been built.  Please note,
+that re-defining @env{LANGUAGES} when calling @samp{make}
+@strong{does not} work anymore!
+
+If the comparison of stage2 and stage3 fails, this normally indicates
+that the stage2 compiler has compiled GCC incorrectly, and is therefore
+a potentially serious bug which you should investigate and report.  (On
+a few systems, meaningful comparison of object files is impossible; they
+always appear ``different''.  If you encounter this problem, you will
+need to disable comparison in the @file{Makefile}.)
+
+If you do not want to bootstrap your compiler, you can configure with
+@option{--disable-bootstrap}.  In particular cases, you may want to
+bootstrap your compiler even if the target system is not the same as
+the one you are building on: for example, you could build a
+@code{powerpc-unknown-linux-gnu} toolchain on a
+@code{powerpc64-unknown-linux-gnu} host.  In this case, pass
+@option{--enable-bootstrap} to the configure script.
+
+@code{BUILD_CONFIG} can be used to bring in additional customization
+to the build.  It can be set to a whitespace-separated list of names.
+For each such @code{NAME}, top-level @file{config/@code{NAME}.mk} will
+be included by the top-level @file{Makefile}, bringing in any settings
+it contains.  The default @code{BUILD_CONFIG} can be set using the
+configure option @option{--with-build-config=@code{NAME}...}.  Some
+examples of supported build configurations are:
+
+@table @asis
+@item @samp{bootstrap-O1}
+Removes any @option{-O}-started option from @code{BOOT_CFLAGS}, and adds
+@option{-O1} to it.  @samp{BUILD_CONFIG=bootstrap-O1} is equivalent to
+@samp{BOOT_CFLAGS='-g -O1'}.
+
+@item @samp{bootstrap-O3}
+Analogous to @code{bootstrap-O1}.
+
+@item @samp{bootstrap-lto}
+Enables Link-Time Optimization for host tools during bootstrapping.
+@samp{BUILD_CONFIG=bootstrap-lto} is equivalent to adding
+@option{-flto} to @samp{BOOT_CFLAGS}.
+
+@item @samp{bootstrap-debug}
+Verifies that the compiler generates the same executable code, whether
+or not it is asked to emit debug information.  To this end, this
+option builds stage2 host programs without debug information, and uses
+@file{contrib/compare-debug} to compare them with the stripped stage3
+object files.  If @code{BOOT_CFLAGS} is overridden so as to not enable
+debug information, stage2 will have it, and stage3 won't.  This option
+is enabled by default when GCC bootstrapping is enabled, if
+@code{strip} can turn object files compiled with and without debug
+info into identical object files.  In addition to better test
+coverage, this option makes default bootstraps faster and leaner.
+
+@item @samp{bootstrap-debug-big}
+Rather than comparing stripped object files, as in
+@code{bootstrap-debug}, this option saves internal compiler dumps
+during stage2 and stage3 and compares them as well, which helps catch
+additional potential problems, but at a great cost in terms of disk
+space.  It can be specified in addition to @samp{bootstrap-debug}.
+
+@item @samp{bootstrap-debug-lean}
+This option saves disk space compared with @code{bootstrap-debug-big},
+but at the expense of some recompilation.  Instead of saving the dumps
+of stage2 and stage3 until the final compare, it uses
+@option{-fcompare-debug} to generate, compare and remove the dumps
+during stage3, repeating the compilation that already took place in
+stage2, whose dumps were not saved.
+
+@item @samp{bootstrap-debug-lib}
+This option tests executable code invariance over debug information
+generation on target libraries, just like @code{bootstrap-debug-lean}
+tests it on host programs.  It builds stage3 libraries with
+@option{-fcompare-debug}, and it can be used along with any of the
+@code{bootstrap-debug} options above.
+
+There aren't @code{-lean} or @code{-big} counterparts to this option
+because most libraries are only build in stage3, so bootstrap compares
+would not get significant coverage.  Moreover, the few libraries built
+in stage2 are used in stage3 host programs, so we wouldn't want to
+compile stage2 libraries with different options for comparison purposes.
+
+@item @samp{bootstrap-debug-ckovw}
+Arranges for error messages to be issued if the compiler built on any
+stage is run without the option @option{-fcompare-debug}.  This is
+useful to verify the full @option{-fcompare-debug} testing coverage.  It
+must be used along with @code{bootstrap-debug-lean} and
+@code{bootstrap-debug-lib}.
+
+@item @samp{bootstrap-time}
+Arranges for the run time of each program started by the GCC driver,
+built in any stage, to be logged to @file{time.log}, in the top level of
+the build tree.
+
+@end table
+
+@section Building a cross compiler
+
+When building a cross compiler, it is not generally possible to do a
+3-stage bootstrap of the compiler.  This makes for an interesting problem
+as parts of GCC can only be built with GCC@.
+
+To build a cross compiler, we recommend first building and installing a
+native compiler.  You can then use the native GCC compiler to build the
+cross compiler.  The installed native compiler needs to be GCC version
+2.95 or later.
+
+If the cross compiler is to be built with support for the Java
+programming language and the ability to compile .java source files is
+desired, the installed native compiler used to build the cross
+compiler needs to be the same GCC version as the cross compiler.  In
+addition the cross compiler needs to be configured with
+@option{--with-ecj-jar=@dots{}}.
+
+Assuming you have already installed a native copy of GCC and configured
+your cross compiler, issue the command @command{make}, which performs the
+following steps:
+
+@itemize @bullet
+@item
+Build host tools necessary to build the compiler.
+
+@item
+Build target tools for use by the compiler such as binutils (bfd,
+binutils, gas, gprof, ld, and opcodes)
+if they have been individually linked or moved into the top level GCC source
+tree before configuring.
+
+@item
+Build the compiler (single stage only).
+
+@item
+Build runtime libraries using the compiler from the previous step.
+@end itemize
+
+Note that if an error occurs in any step the make process will exit.
+
+If you are not building GNU binutils in the same source tree as GCC,
+you will need a cross-assembler and cross-linker installed before
+configuring GCC@.  Put them in the directory
+@file{@var{prefix}/@var{target}/bin}.  Here is a table of the tools
+you should put in this directory:
+
+@table @file
+@item as
+This should be the cross-assembler.
+
+@item ld
+This should be the cross-linker.
+
+@item ar
+This should be the cross-archiver: a program which can manipulate
+archive files (linker libraries) in the target machine's format.
+
+@item ranlib
+This should be a program to construct a symbol table in an archive file.
+@end table
+
+The installation of GCC will find these programs in that directory,
+and copy or link them to the proper place to for the cross-compiler to
+find them when run later.
+
+The easiest way to provide these files is to build the Binutils package.
+Configure it with the same @option{--host} and @option{--target}
+options that you use for configuring GCC, then build and install
+them.  They install their executables automatically into the proper
+directory.  Alas, they do not support all the targets that GCC
+supports.
+
+If you are not building a C library in the same source tree as GCC,
+you should also provide the target libraries and headers before
+configuring GCC, specifying the directories with
+@option{--with-sysroot} or @option{--with-headers} and
+@option{--with-libs}.  Many targets also require ``start files'' such
+as @file{crt0.o} and
+@file{crtn.o} which are linked into each executable.  There may be several
+alternatives for @file{crt0.o}, for use with profiling or other
+compilation options.  Check your target's definition of
+@code{STARTFILE_SPEC} to find out what start files it uses.
+
+@section Building in parallel
+
+GNU Make 3.80 and above, which is necessary to build GCC, support
+building in parallel.  To activate this, you can use @samp{make -j 2}
+instead of @samp{make}.  You can also specify a bigger number, and
+in most cases using a value greater than the number of processors in
+your machine will result in fewer and shorter I/O latency hits, thus
+improving overall throughput; this is especially true for slow drives
+and network filesystems.
+
+@section Building the Ada compiler
+
+In order to build GNAT, the Ada compiler, you need a working GNAT
+compiler (GCC version 4.0 or later).
+This includes GNAT tools such as @command{gnatmake} and
+@command{gnatlink}, since the Ada front end is written in Ada and
+uses some GNAT-specific extensions.
+
+In order to build a cross compiler, it is suggested to install
+the new compiler as native first, and then use it to build the cross
+compiler.
+
+@command{configure} does not test whether the GNAT installation works
+and has a sufficiently recent version; if too old a GNAT version is
+installed, the build will fail unless @option{--enable-languages} is
+used to disable building the Ada front end.
+
+@env{ADA_INCLUDE_PATH} and @env{ADA_OBJECT_PATH} environment variables
+must not be set when building the Ada compiler, the Ada tools, or the
+Ada runtime libraries. You can check that your build environment is clean
+by verifying that @samp{gnatls -v} lists only one explicit path in each
+section.
+
+@section Building with profile feedback
+
+It is possible to use profile feedback to optimize the compiler itself.  This
+should result in a faster compiler binary.  Experiments done on x86 using gcc
+3.3 showed approximately 7 percent speedup on compiling C programs.  To
+bootstrap the compiler with profile feedback, use @code{make profiledbootstrap}.
+
+When @samp{make profiledbootstrap} is run, it will first build a @code{stage1}
+compiler.  This compiler is used to build a @code{stageprofile} compiler
+instrumented to collect execution counts of instruction and branch
+probabilities.  Then runtime libraries are compiled with profile collected.
+Finally a @code{stagefeedback} compiler is built using the information collected.
+
+Unlike standard bootstrap, several additional restrictions apply.  The
+compiler used to build @code{stage1} needs to support a 64-bit integral type.
+It is recommended to only use GCC for this.  Also parallel make is currently
+not supported since collisions in profile collecting may occur.
+
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+
+@c ***Testing*****************************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Testing, Final install, Building, Installing GCC
+@end ifnothtml
+@ifset testhtml
+@ifnothtml
+@chapter Installing GCC: Testing
+@end ifnothtml
+@cindex Testing
+@cindex Installing GCC: Testing
+@cindex Testsuite
+
+Before you install GCC, we encourage you to run the testsuites and to
+compare your results with results from a similar configuration that have
+been submitted to the
+@uref{http://gcc.gnu.org/ml/gcc-testresults/,,gcc-testresults mailing list}.
+Some of these archived results are linked from the build status lists
+at @uref{http://gcc.gnu.org/buildstat.html}, although not everyone who
+reports a successful build runs the testsuites and submits the results.
+This step is optional and may require you to download additional software,
+but it can give you confidence in your new GCC installation or point out
+problems before you install and start using your new GCC@.
+
+First, you must have @uref{download.html,,downloaded the testsuites}.
+These are part of the full distribution, but if you downloaded the
+``core'' compiler plus any front ends, you must download the testsuites
+separately.
+
+Second, you must have the testing tools installed.  This includes
+@uref{http://www.gnu.org/software/dejagnu/,,DejaGnu}, Tcl, and Expect;
+the DejaGnu site has links to these.
+
+If the directories where @command{runtest} and @command{expect} were
+installed are not in the @env{PATH}, you may need to set the following
+environment variables appropriately, as in the following example (which
+assumes that DejaGnu has been installed under @file{/usr/local}):
+
+@smallexample
+TCL_LIBRARY = /usr/local/share/tcl8.0
+DEJAGNULIBS = /usr/local/share/dejagnu
+@end smallexample
+
+(On systems such as Cygwin, these paths are required to be actual
+paths, not mounts or links; presumably this is due to some lack of
+portability in the DejaGnu code.)
+
+
+Finally, you can run the testsuite (which may take a long time):
+@smallexample
+cd @var{objdir}; make -k check
+@end smallexample
+
+This will test various components of GCC, such as compiler
+front ends and runtime libraries.  While running the testsuite, DejaGnu
+might emit some harmless messages resembling
+@samp{WARNING: Couldn't find the global config file.} or
+@samp{WARNING: Couldn't find tool init file} that can be ignored.
+
+If you are testing a cross-compiler, you may want to run the testsuite
+on a simulator as described at @uref{http://gcc.gnu.org/simtest-howto.html}.
+
+@section How can you run the testsuite on selected tests?
+
+In order to run sets of tests selectively, there are targets
+@samp{make check-gcc} and language specific @samp{make check-c},
+@samp{make check-c++}, @samp{make check-fortran}, @samp{make check-java},
+@samp{make check-ada}, @samp{make check-objc}, @samp{make check-obj-c++},
+@samp{make check-lto}
+in the @file{gcc} subdirectory of the object directory.  You can also
+just run @samp{make check} in a subdirectory of the object directory.
+
+
+A more selective way to just run all @command{gcc} execute tests in the
+testsuite is to use
+
+@smallexample
+make check-gcc RUNTESTFLAGS="execute.exp @var{other-options}"
+@end smallexample
+
+Likewise, in order to run only the @command{g++} ``old-deja'' tests in
+the testsuite with filenames matching @samp{9805*}, you would use
+
+@smallexample
+make check-g++ RUNTESTFLAGS="old-deja.exp=9805* @var{other-options}"
+@end smallexample
+
+The @file{*.exp} files are located in the testsuite directories of the GCC
+source, the most important ones being @file{compile.exp},
+@file{execute.exp}, @file{dg.exp} and @file{old-deja.exp}.
+To get a list of the possible @file{*.exp} files, pipe the
+output of @samp{make check} into a file and look at the
+@samp{Running @dots{}  .exp} lines.
+
+@section Passing options and running multiple testsuites
+
+You can pass multiple options to the testsuite using the
+@samp{--target_board} option of DejaGNU, either passed as part of
+@samp{RUNTESTFLAGS}, or directly to @command{runtest} if you prefer to
+work outside the makefiles.  For example,
+
+@smallexample
+make check-g++ RUNTESTFLAGS="--target_board=unix/-O3/-fmerge-constants"
+@end smallexample
+
+will run the standard @command{g++} testsuites (``unix'' is the target name
+for a standard native testsuite situation), passing
+@samp{-O3 -fmerge-constants} to the compiler on every test, i.e.,
+slashes separate options.
+
+You can run the testsuites multiple times using combinations of options
+with a syntax similar to the brace expansion of popular shells:
+
+@smallexample
+@dots{}"--target_board=arm-sim\@{-mhard-float,-msoft-float\@}\@{-O1,-O2,-O3,\@}"
+@end smallexample
+
+(Note the empty option caused by the trailing comma in the final group.)
+The following will run each testsuite eight times using the @samp{arm-sim}
+target, as if you had specified all possible combinations yourself:
+
+@smallexample
+--target_board='arm-sim/-mhard-float/-O1 \
+                arm-sim/-mhard-float/-O2 \
+                arm-sim/-mhard-float/-O3 \
+                arm-sim/-mhard-float \
+                arm-sim/-msoft-float/-O1 \
+                arm-sim/-msoft-float/-O2 \
+                arm-sim/-msoft-float/-O3 \
+                arm-sim/-msoft-float'
+@end smallexample
+
+They can be combined as many times as you wish, in arbitrary ways.  This
+list:
+
+@smallexample
+@dots{}"--target_board=unix/-Wextra\@{-O3,-fno-strength\@}\@{-fomit-frame,\@}"
+@end smallexample
+
+will generate four combinations, all involving @samp{-Wextra}.
+
+The disadvantage to this method is that the testsuites are run in serial,
+which is a waste on multiprocessor systems.  For users with GNU Make and
+a shell which performs brace expansion, you can run the testsuites in
+parallel by having the shell perform the combinations and @command{make}
+do the parallel runs.  Instead of using @samp{--target_board}, use a
+special makefile target:
+
+@smallexample
+make -j@var{N} check-@var{testsuite}//@var{test-target}/@var{option1}/@var{option2}/@dots{}
+@end smallexample
+
+For example,
+
+@smallexample
+make -j3 check-gcc//sh-hms-sim/@{-m1,-m2,-m3,-m3e,-m4@}/@{,-nofpu@}
+@end smallexample
+
+will run three concurrent ``make-gcc'' testsuites, eventually testing all
+ten combinations as described above.  Note that this is currently only
+supported in the @file{gcc} subdirectory.  (To see how this works, try
+typing @command{echo} before the example given here.)
+
+
+@section Additional testing for Java Class Libraries
+
+The Java runtime tests can be executed via @samp{make check}
+in the @file{@var{target}/libjava/testsuite} directory in
+the build tree.
+
+The @uref{http://sourceware.org/mauve/,,Mauve Project} provides
+a suite of tests for the Java Class Libraries.  This suite can be run
+as part of libgcj testing by placing the Mauve tree within the libjava
+testsuite at @file{libjava/testsuite/libjava.mauve/mauve}, or by
+specifying the location of that tree when invoking @samp{make}, as in
+@samp{make MAUVEDIR=~/mauve check}.
+
+@section How to interpret test results
+
+The result of running the testsuite are various @file{*.sum} and @file{*.log}
+files in the testsuite subdirectories.  The @file{*.log} files contain a
+detailed log of the compiler invocations and the corresponding
+results, the @file{*.sum} files summarize the results.  These summaries
+contain status codes for all tests:
+
+@itemize @bullet
+@item
+PASS: the test passed as expected
+@item
+XPASS: the test unexpectedly passed
+@item
+FAIL: the test unexpectedly failed
+@item
+XFAIL: the test failed as expected
+@item
+UNSUPPORTED: the test is not supported on this platform
+@item
+ERROR: the testsuite detected an error
+@item
+WARNING: the testsuite detected a possible problem
+@end itemize
+
+It is normal for some tests to report unexpected failures.  At the
+current time the testing harness does not allow fine grained control
+over whether or not a test is expected to fail.  This problem should
+be fixed in future releases.
+
+
+@section Submitting test results
+
+If you want to report the results to the GCC project, use the
+@file{contrib/test_summary} shell script.  Start it in the @var{objdir} with
+
+@smallexample
+@var{srcdir}/contrib/test_summary -p your_commentary.txt \
+    -m gcc-testresults@@gcc.gnu.org |sh
+@end smallexample
+
+This script uses the @command{Mail} program to send the results, so
+make sure it is in your @env{PATH}.  The file @file{your_commentary.txt} is
+prepended to the testsuite summary and should contain any special
+remarks you have on your results or your build environment.  Please
+do not edit the testsuite result block or the subject line, as these
+messages may be automatically processed.
+
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+
+@c ***Final install***********************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Final install, , Testing, Installing GCC
+@end ifnothtml
+@ifset finalinstallhtml
+@ifnothtml
+@chapter Installing GCC: Final installation
+@end ifnothtml
+
+Now that GCC has been built (and optionally tested), you can install it with
+@smallexample
+cd @var{objdir} && make install
+@end smallexample
+
+We strongly recommend to install into a target directory where there is
+no previous version of GCC present.  Also, the GNAT runtime should not
+be stripped, as this would break certain features of the debugger that
+depend on this debugging information (catching Ada exceptions for
+instance).
+
+That step completes the installation of GCC; user level binaries can
+be found in @file{@var{prefix}/bin} where @var{prefix} is the value
+you specified with the @option{--prefix} to configure (or
+@file{/usr/local} by default).  (If you specified @option{--bindir},
+that directory will be used instead; otherwise, if you specified
+@option{--exec-prefix}, @file{@var{exec-prefix}/bin} will be used.)
+Headers for the C++ and Java libraries are installed in
+@file{@var{prefix}/include}; libraries in @file{@var{libdir}}
+(normally @file{@var{prefix}/lib}); internal parts of the compiler in
+@file{@var{libdir}/gcc} and @file{@var{libexecdir}/gcc}; documentation
+in info format in @file{@var{infodir}} (normally
+@file{@var{prefix}/info}).
+
+When installing cross-compilers, GCC's executables
+are not only installed into @file{@var{bindir}}, that
+is, @file{@var{exec-prefix}/bin}, but additionally into
+@file{@var{exec-prefix}/@var{target-alias}/bin}, if that directory
+exists.  Typically, such @dfn{tooldirs} hold target-specific
+binutils, including assembler and linker.
+
+Installation into a temporary staging area or into a @command{chroot}
+jail can be achieved with the command
+
+@smallexample
+make DESTDIR=@var{path-to-rootdir} install
+@end smallexample
+
+@noindent
+where @var{path-to-rootdir} is the absolute path of
+a directory relative to which all installation paths will be
+interpreted.  Note that the directory specified by @code{DESTDIR}
+need not exist yet; it will be created if necessary.
+
+There is a subtle point with tooldirs and @code{DESTDIR}:
+If you relocate a cross-compiler installation with
+e.g.@: @samp{DESTDIR=@var{rootdir}}, then the directory
+@file{@var{rootdir}/@var{exec-prefix}/@var{target-alias}/bin} will
+be filled with duplicated GCC executables only if it already exists,
+it will not be created otherwise.  This is regarded as a feature,
+not as a bug, because it gives slightly more control to the packagers
+using the @code{DESTDIR} feature.
+
+You can install stripped programs and libraries with
+
+@smallexample
+make install-strip
+@end smallexample
+
+If you are bootstrapping a released version of GCC then please
+quickly review the build status page for your release, available from
+@uref{http://gcc.gnu.org/buildstat.html}.
+If your system is not listed for the version of GCC that you built,
+send a note to
+@email{gcc@@gcc.gnu.org} indicating
+that you successfully built and installed GCC@.
+Include the following information:
+
+@itemize @bullet
+@item
+Output from running @file{@var{srcdir}/config.guess}.  Do not send
+that file itself, just the one-line output from running it.
+
+@item
+The output of @samp{gcc -v} for your newly installed @command{gcc}.
+This tells us which version of GCC you built and the options you passed to
+configure.
+
+@item
+Whether you enabled all languages or a subset of them.  If you used a
+full distribution then this information is part of the configure
+options in the output of @samp{gcc -v}, but if you downloaded the
+``core'' compiler plus additional front ends then it isn't apparent
+which ones you built unless you tell us about it.
+
+@item
+If the build was for GNU/Linux, also include:
+@itemize @bullet
+@item
+The distribution name and version (e.g., Red Hat 7.1 or Debian 2.2.3);
+this information should be available from @file{/etc/issue}.
+
+@item
+The version of the Linux kernel, available from @samp{uname --version}
+or @samp{uname -a}.
+
+@item
+The version of glibc you used; for RPM-based systems like Red Hat,
+Mandrake, and SuSE type @samp{rpm -q glibc} to get the glibc version,
+and on systems like Debian and Progeny use @samp{dpkg -l libc6}.
+@end itemize
+For other systems, you can include similar information if you think it is
+relevant.
+
+@item
+Any other information that you think would be useful to people building
+GCC on the same configuration.  The new entry in the build status list
+will include a link to the archived copy of your message.
+@end itemize
+
+We'd also like to know if the
+@ifnothtml
+@ref{Specific, host/target specific installation notes}
+@end ifnothtml
+@ifhtml
+@uref{specific.html,,host/target specific installation notes}
+@end ifhtml
+didn't include your host/target information or if that information is
+incomplete or out of date.  Send a note to
+@email{gcc@@gcc.gnu.org} detailing how the information should be changed.
+
+If you find a bug, please report it following the
+@uref{../bugs/,,bug reporting guidelines}.
+
+If you want to print the GCC manuals, do @samp{cd @var{objdir}; make
+dvi}.  You will need to have @command{texi2dvi} (version at least 4.7)
+and @TeX{} installed.  This creates a number of @file{.dvi} files in
+subdirectories of @file{@var{objdir}}; these may be converted for
+printing with programs such as @command{dvips}.  Alternately, by using
+@samp{make pdf} in place of @samp{make dvi}, you can create documentation
+in the form of @file{.pdf} files; this requires @command{texi2pdf}, which
+is included with Texinfo version 4.8 and later.  You can also
+@uref{http://shop.fsf.org/,,buy printed manuals from the
+Free Software Foundation}, though such manuals may not be for the most
+recent version of GCC@.
+
+If you would like to generate online HTML documentation, do @samp{cd
+@var{objdir}; make html} and HTML will be generated for the gcc manuals in
+@file{@var{objdir}/gcc/HTML}.
+
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+
+@c ***Binaries****************************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Binaries, Specific, Installing GCC, Top
+@end ifnothtml
+@ifset binarieshtml
+@ifnothtml
+@chapter Installing GCC: Binaries
+@end ifnothtml
+@cindex Binaries
+@cindex Installing GCC: Binaries
+
+We are often asked about pre-compiled versions of GCC@.  While we cannot
+provide these for all platforms, below you'll find links to binaries for
+various platforms where creating them by yourself is not easy due to various
+reasons.
+
+Please note that we did not create these binaries, nor do we
+support them.  If you have any problems installing them, please
+contact their makers.
+
+@itemize
+@item
+AIX:
+@itemize
+@item
+@uref{http://www.bullfreeware.com,,Bull's Freeware and Shareware Archive for AIX};
+
+@item
+@uref{http://pware.hvcc.edu,,Hudson Valley Community College Open Source Software for IBM System p};
+
+@item
+@uref{http://www.perzl.org/aix/,,AIX 5L and 6 Open Source Packages}.
+@end itemize
+
+@item
+DOS---@uref{http://www.delorie.com/djgpp/,,DJGPP}.
+
+@item
+Renesas H8/300[HS]---@uref{http://h8300-hms.sourceforge.net/,,GNU
+Development Tools for the Renesas H8/300[HS] Series}.
+
+@item
+HP-UX:
+@itemize
+@item
+@uref{http://hpux.connect.org.uk/,,HP-UX Porting Center};
+
+@item
+@uref{ftp://sunsite.informatik.rwth-aachen.de/pub/packages/gcc_hpux/,,Binaries for HP-UX 11.00 at Aachen University of Technology}.
+@end itemize
+
+@item
+@uref{http://www.sco.com/skunkware/devtools/index.html#gcc,,SCO
+OpenServer/Unixware}.
+
+@item
+Solaris 2 (SPARC, Intel):
+@itemize
+@item
+@uref{http://www.sunfreeware.com/,,Sunfreeware}
+
+@item
+@uref{http://www.blastwave.org/,,Blastwave}
+
+@item
+@uref{http://www.opencsw.org/,,OpenCSW}
+
+@item
+@uref{http://jupiterrise.com/tgcware/,,TGCware}
+@end itemize
+
+@item
+Microsoft Windows:
+@itemize
+@item
+The @uref{http://sourceware.org/cygwin/,,Cygwin} project;
+@item
+The @uref{http://www.mingw.org/,,MinGW} project.
+@end itemize
+
+@item
+@uref{ftp://ftp.thewrittenword.com/packages/by-name/,,The
+Written Word} offers binaries for
+AIX 4.3.3, 5.1 and 5.2,
+GNU/Linux (i386),
+HP-UX 10.20, 11.00, and 11.11, and
+Solaris/SPARC 2.5.1, 2.6, 7, 8, 9 and 10.
+
+@item
+@uref{http://www.openpkg.org/,,OpenPKG} offers binaries for quite a
+number of platforms.
+
+@item
+The @uref{http://gcc.gnu.org/wiki/GFortranBinaries,,GFortran Wiki} has
+links to GNU Fortran binaries for several platforms.
+@end itemize
+
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+
+@c ***Specific****************************************************************
+@ifnothtml
+@comment node-name,     next,          previous, up
+@node    Specific, Old, Binaries, Top
+@end ifnothtml
+@ifset specifichtml
+@ifnothtml
+@chapter Host/target specific installation notes for GCC
+@end ifnothtml
+@cindex Specific
+@cindex Specific installation notes
+@cindex Target specific installation
+@cindex Host specific installation
+@cindex Target specific installation notes
+
+Please read this document carefully @emph{before} installing the
+GNU Compiler Collection on your machine.
+
+Note that this list of install notes is @emph{not} a list of supported
+hosts or targets.  Not all supported hosts and targets are listed
+here, only the ones that require host-specific or target-specific
+information have to. 
+
+@ifhtml
+@itemize
+@item
+@uref{#alpha-x-x,,alpha*-*-*}
+@item
+@uref{#alpha-dec-osf51,,alpha*-dec-osf5.1}
+@item
+@uref{#amd64-x-solaris210,,amd64-*-solaris2.10}
+@item
+@uref{#arm-x-eabi,,arm-*-eabi}
+@item
+@uref{#avr,,avr}
+@item
+@uref{#bfin,,Blackfin}
+@item
+@uref{#dos,,DOS}
+@item
+@uref{#x-x-freebsd,,*-*-freebsd*}
+@item
+@uref{#h8300-hms,,h8300-hms}
+@item
+@uref{#hppa-hp-hpux,,hppa*-hp-hpux*}
+@item
+@uref{#hppa-hp-hpux10,,hppa*-hp-hpux10}
+@item
+@uref{#hppa-hp-hpux11,,hppa*-hp-hpux11}
+@item
+@uref{#x-x-linux-gnu,,*-*-linux-gnu}
+@item
+@uref{#ix86-x-linux,,i?86-*-linux*}
+@item
+@uref{#ix86-x-solaris289,,i?86-*-solaris2.9}
+@item
+@uref{#ix86-x-solaris210,,i?86-*-solaris2.10}
+@item
+@uref{#ia64-x-linux,,ia64-*-linux}
+@item
+@uref{#ia64-x-hpux,,ia64-*-hpux*}
+@item
+@uref{#x-ibm-aix,,*-ibm-aix*}
+@item
+@uref{#iq2000-x-elf,,iq2000-*-elf}
+@item
+@uref{#lm32-x-elf,,lm32-*-elf}
+@item
+@uref{#lm32-x-uclinux,,lm32-*-uclinux}
+@item
+@uref{#m32c-x-elf,,m32c-*-elf}
+@item
+@uref{#m32r-x-elf,,m32r-*-elf}
+@item
+@uref{#m68k-x-x,,m68k-*-*}
+@item
+@uref{#m68k-uclinux,,m68k-uclinux}
+@item
+@uref{#mep-x-elf,,mep-*-elf}
+@item
+@uref{#microblaze-x-elf,,microblaze-*-elf}
+@item
+@uref{#mips-x-x,,mips-*-*}
+@item
+@uref{#mips-sgi-irix5,,mips-sgi-irix5}
+@item
+@uref{#mips-sgi-irix6,,mips-sgi-irix6}
+@item
+@uref{#powerpc-x-x,,powerpc*-*-*}
+@item
+@uref{#powerpc-x-darwin,,powerpc-*-darwin*}
+@item
+@uref{#powerpc-x-elf,,powerpc-*-elf}
+@item
+@uref{#powerpc-x-linux-gnu,,powerpc*-*-linux-gnu*}
+@item
+@uref{#powerpc-x-netbsd,,powerpc-*-netbsd*}
+@item
+@uref{#powerpc-x-eabisim,,powerpc-*-eabisim}
+@item
+@uref{#powerpc-x-eabi,,powerpc-*-eabi}
+@item
+@uref{#powerpcle-x-elf,,powerpcle-*-elf}
+@item
+@uref{#powerpcle-x-eabisim,,powerpcle-*-eabisim}
+@item
+@uref{#powerpcle-x-eabi,,powerpcle-*-eabi}
+@item
+@uref{#s390-x-linux,,s390-*-linux*}
+@item
+@uref{#s390x-x-linux,,s390x-*-linux*}
+@item
+@uref{#s390x-ibm-tpf,,s390x-ibm-tpf*}
+@item
+@uref{#x-x-solaris2,,*-*-solaris2*}
+@item
+@uref{#sparc-x-x,,sparc*-*-*}
+@item
+@uref{#sparc-sun-solaris2,,sparc-sun-solaris2*}
+@item
+@uref{#sparc-sun-solaris210,,sparc-sun-solaris2.10}
+@item
+@uref{#sparc-x-linux,,sparc-*-linux*}
+@item
+@uref{#sparc64-x-solaris2,,sparc64-*-solaris2*}
+@item
+@uref{#sparcv9-x-solaris2,,sparcv9-*-solaris2*}
+@item
+@uref{#c6x-x-x,,c6x-*-*}
+@item
+@uref{#tilegx-x-linux,,tilegx-*-linux*}
+@item
+@uref{#tilegxbe-x-linux,,tilegxbe-*-linux*}
+@item
+@uref{#tilepro-x-linux,,tilepro-*-linux*}
+@item
+@uref{#x-x-vxworks,,*-*-vxworks*}
+@item
+@uref{#x86-64-x-x,,x86_64-*-*, amd64-*-*}
+@item
+@uref{#x86-64-x-solaris210,,x86_64-*-solaris2.1[0-9]*}
+@item
+@uref{#xtensa-x-elf,,xtensa*-*-elf}
+@item
+@uref{#xtensa-x-linux,,xtensa*-*-linux*}
+@item
+@uref{#windows,,Microsoft Windows}
+@item
+@uref{#x-x-cygwin,,*-*-cygwin}
+@item
+@uref{#x-x-interix,,*-*-interix}
+@item
+@uref{#x-x-mingw32,,*-*-mingw32}
+@item
+@uref{#os2,,OS/2}
+@item
+@uref{#older,,Older systems}
+@end itemize
+
+@itemize
+@item
+@uref{#elf,,all ELF targets} (SVR4, Solaris 2, etc.)
+@end itemize
+@end ifhtml
+
+
+@html
+<!-- -------- host/target specific issues start here ---------------- -->
+<hr />
+@end html
+@anchor{alpha-x-x}
+@heading alpha*-*-*
+This section contains general configuration information for all
+alpha-based platforms using ELF (in particular, ignore this section for
+DEC OSF/1, Digital UNIX and Tru64 UNIX)@.  In addition to reading this
+section, please read all other sections that match your target.
+
+We require binutils 2.11.2 or newer.
+Previous binutils releases had a number of problems with DWARF 2
+debugging information, not the least of which is incorrect linking of
+shared libraries.
+
+@html
+<hr />
+@end html
+@anchor{alpha-dec-osf51}
+@heading alpha*-dec-osf5.1
+Systems using processors that implement the DEC Alpha architecture and
+are running the DEC/Compaq/HP Unix (DEC OSF/1, Digital UNIX, or Compaq/HP
+Tru64 UNIX) operating system, for example the DEC Alpha AXP systems.
+
+Support for Tru64 UNIX V5.1 has been removed in GCC 4.8.  As of GCC 4.6,
+support for Tru64 UNIX V4.0 and V5.0 has been removed.  As of GCC 3.2,
+versions before @code{alpha*-dec-osf4} are no longer supported.  (These
+are the versions which identify themselves as DEC OSF/1.)
+
+@html
+<hr />
+@end html
+@anchor{amd64-x-solaris210}
+@heading amd64-*-solaris2.1[0-9]*
+This is a synonym for @samp{x86_64-*-solaris2.1[0-9]*}.
+
+@html
+<hr />
+@end html
+@anchor{arc-x-elf32}
+@heading arc-*-elf32
+
+Use @samp{configure --target=arc-elf32 --with-cpu=@var{cpu} --enable-languages="c,c++"}
+to configure GCC, with @var{cpu} being one of @samp{arc600}, @samp{arc601},
+or @samp{arc700}@.
+
+@html
+<hr />
+@end html
+@anchor{arc-linux-uclibc}
+@heading arc-linux-uclibc
+
+Use @samp{configure --target=arc-linux-uclibc --with-cpu=arc700 --enable-languages="c,c++"} to configure GCC@.
+
+@html
+<hr />
+@end html
+@anchor{arm-x-eabi}
+@heading arm-*-eabi
+ARM-family processors.  Subtargets that use the ELF object format
+require GNU binutils 2.13 or newer.  Such subtargets include:
+@code{arm-*-netbsdelf}, @code{arm-*-*linux-*}
+and @code{arm-*-rtemseabi}.
+
+@html
+<hr />
+@end html
+@anchor{avr}
+@heading avr
+ATMEL AVR-family micro controllers.  These are used in embedded
+applications.  There are no standard Unix configurations.
+@ifnothtml
+@xref{AVR Options,, AVR Options, gcc, Using the GNU Compiler
+Collection (GCC)},
+@end ifnothtml
+@ifhtml
+See ``AVR Options'' in the main manual
+@end ifhtml
+for the list of supported MCU types.
+
+Use @samp{configure --target=avr --enable-languages="c"} to configure GCC@.
+
+Further installation notes and other useful information about AVR tools
+can also be obtained from:
+
+@itemize @bullet
+@item
+@uref{http://www.nongnu.org/avr/,,http://www.nongnu.org/avr/}
+@item
+@uref{http://www.amelek.gda.pl/avr/,,http://www.amelek.gda.pl/avr/}
+@end itemize
+
+We @emph{strongly} recommend using binutils 2.13 or newer.
+
+The following error:
+@smallexample
+Error: register required
+@end smallexample
+
+indicates that you should upgrade to a newer version of the binutils.
+
+@html
+<hr />
+@end html
+@anchor{bfin}
+@heading Blackfin
+The Blackfin processor, an Analog Devices DSP.
+@ifnothtml
+@xref{Blackfin Options,, Blackfin Options, gcc, Using the GNU Compiler
+Collection (GCC)},
+@end ifnothtml
+@ifhtml
+See ``Blackfin Options'' in the main manual
+@end ifhtml
+
+More information, and a version of binutils with support for this processor,
+is available at @uref{http://blackfin.uclinux.org}
+
+@html
+<hr />
+@end html
+@anchor{cr16}
+@heading CR16
+The CR16 CompactRISC architecture is a 16-bit architecture. This
+architecture is used in embedded applications.
+
+@ifnothtml
+@xref{CR16 Options,, CR16 Options, gcc, Using and Porting the GNU Compiler
+Collection (GCC)},
+@end ifnothtml
+
+@ifhtml
+See ``CR16 Options'' in the main manual for a list of CR16-specific options.
+@end ifhtml
+
+Use @samp{configure --target=cr16-elf --enable-languages=c,c++} to configure
+GCC@ for building a CR16 elf cross-compiler.
+
+Use @samp{configure --target=cr16-uclinux --enable-languages=c,c++} to
+configure GCC@ for building a CR16 uclinux cross-compiler.
+
+@html
+<hr />
+@end html
+@anchor{cris}
+@heading CRIS
+CRIS is the CPU architecture in Axis Communications ETRAX system-on-a-chip
+series.  These are used in embedded applications.
+
+@ifnothtml
+@xref{CRIS Options,, CRIS Options, gcc, Using the GNU Compiler
+Collection (GCC)},
+@end ifnothtml
+@ifhtml
+See ``CRIS Options'' in the main manual
+@end ifhtml
+for a list of CRIS-specific options.
+
+There are a few different CRIS targets:
+@table @code
+@item cris-axis-elf
+Mainly for monolithic embedded systems.  Includes a multilib for the
+@samp{v10} core used in @samp{ETRAX 100 LX}.
+@item cris-axis-linux-gnu
+A GNU/Linux port for the CRIS architecture, currently targeting
+@samp{ETRAX 100 LX} by default.
+@end table
+
+For @code{cris-axis-elf} you need binutils 2.11
+or newer.  For @code{cris-axis-linux-gnu} you need binutils 2.12 or newer.
+
+Pre-packaged tools can be obtained from
+@uref{ftp://ftp.axis.com/@/pub/@/axis/@/tools/@/cris/@/compiler-kit/}.  More
+information about this platform is available at
+@uref{http://developer.axis.com/}.
+
+@html
+<hr />
+@end html
+@anchor{dos}
+@heading DOS
+Please have a look at the @uref{binaries.html,,binaries page}.
+
+You cannot install GCC by itself on MSDOS; it will not compile under
+any MSDOS compiler except itself.  You need to get the complete
+compilation package DJGPP, which includes binaries as well as sources,
+and includes all the necessary compilation tools and libraries.
+
+@html
+<hr />
+@end html
+@anchor{epiphany-x-elf}
+@heading epiphany-*-elf
+Adapteva Epiphany.
+This configuration is intended for embedded systems.
+
+@html
+<hr />
+@end html
+@anchor{x-x-freebsd}
+@heading *-*-freebsd*
+Support for FreeBSD 1 was discontinued in GCC 3.2.  Support for
+FreeBSD 2 (and any mutant a.out variants of FreeBSD 3) was
+discontinued in GCC 4.0.
+
+In order to better utilize FreeBSD base system functionality and match
+the configuration of the system compiler, GCC 4.5 and above as well as
+GCC 4.4 past 2010-06-20 leverage SSP support in libc (which is present
+on FreeBSD 7 or later) and the use of @code{__cxa_atexit} by default
+(on FreeBSD 6 or later).  The use of @code{dl_iterate_phdr} inside
+@file{libgcc_s.so.1} and boehm-gc (on FreeBSD 7 or later) is enabled
+by GCC 4.5 and above.
+
+We support FreeBSD using the ELF file format with DWARF 2 debugging
+for all CPU architectures.  You may use @option{-gstabs} instead of
+@option{-g}, if you really want the old debugging format.  There are
+no known issues with mixing object files and libraries with different
+debugging formats.  Otherwise, this release of GCC should now match
+more of the configuration used in the stock FreeBSD configuration of
+GCC@.  In particular, @option{--enable-threads} is now configured by
+default.  However, as a general user, do not attempt to replace the
+system compiler with this release.  Known to bootstrap and check with
+good results on FreeBSD 7.2-STABLE@.  In the past, known to bootstrap
+and check with good results on FreeBSD 3.0, 3.4, 4.0, 4.2, 4.3, 4.4,
+4.5, 4.8, 4.9 and 5-CURRENT@.
+
+The version of binutils installed in @file{/usr/bin} probably works
+with this release of GCC@.  Bootstrapping against the latest GNU
+binutils and/or the version found in @file{/usr/ports/devel/binutils} has
+been known to enable additional features and improve overall testsuite
+results.  However, it is currently known that boehm-gc (which itself
+is required for java) may not configure properly on FreeBSD prior to
+the FreeBSD 7.0 release with GNU binutils after 2.16.1.
+
+@html
+<hr />
+@end html
+@anchor{h8300-hms}
+@heading h8300-hms
+Renesas H8/300 series of processors.
+
+Please have a look at the @uref{binaries.html,,binaries page}.
+
+The calling convention and structure layout has changed in release 2.6.
+All code must be recompiled.  The calling convention now passes the
+first three arguments in function calls in registers.  Structures are no
+longer a multiple of 2 bytes.
+
+@html
+<hr />
+@end html
+@anchor{hppa-hp-hpux}
+@heading hppa*-hp-hpux*
+Support for HP-UX version 9 and older was discontinued in GCC 3.4.
+
+We require using gas/binutils on all hppa platforms.  Version 2.19 or
+later is recommended.
+
+It may be helpful to configure GCC with the
+@uref{./configure.html#with-gnu-as,,@option{--with-gnu-as}} and
+@option{--with-as=@dots{}} options to ensure that GCC can find GAS@.
+
+The HP assembler should not be used with GCC.  It is rarely tested and may
+not work.  It shouldn't be used with any languages other than C due to its
+many limitations.
+
+Specifically, @option{-g} does not work (HP-UX uses a peculiar debugging
+format which GCC does not know about).  It also inserts timestamps
+into each object file it creates, causing the 3-stage comparison test to
+fail during a bootstrap.  You should be able to continue by saying
+@samp{make all-host all-target} after getting the failure from @samp{make}.
+
+Various GCC features are not supported.  For example, it does not support weak
+symbols or alias definitions.  As a result, explicit template instantiations
+are required when using C++.  This makes it difficult if not impossible to
+build many C++ applications.
+
+There are two default scheduling models for instructions.  These are
+PROCESSOR_7100LC and PROCESSOR_8000.  They are selected from the pa-risc
+architecture specified for the target machine when configuring.
+PROCESSOR_8000 is the default.  PROCESSOR_7100LC is selected when
+the target is a @samp{hppa1*} machine.
+
+The PROCESSOR_8000 model is not well suited to older processors.  Thus,
+it is important to completely specify the machine architecture when
+configuring if you want a model other than PROCESSOR_8000.  The macro
+TARGET_SCHED_DEFAULT can be defined in BOOT_CFLAGS if a different
+default scheduling model is desired.
+
+As of GCC 4.0, GCC uses the UNIX 95 namespace for HP-UX 10.10
+through 11.00, and the UNIX 98 namespace for HP-UX 11.11 and later.
+This namespace change might cause problems when bootstrapping with
+an earlier version of GCC or the HP compiler as essentially the same
+namespace is required for an entire build.  This problem can be avoided
+in a number of ways.  With HP cc, @env{UNIX_STD} can be set to @samp{95}
+or @samp{98}.  Another way is to add an appropriate set of predefines
+to @env{CC}.  The description for the @option{munix=} option contains
+a list of the predefines used with each standard.
+
+More specific information to @samp{hppa*-hp-hpux*} targets follows.
+
+@html
+<hr />
+@end html
+@anchor{hppa-hp-hpux10}
+@heading hppa*-hp-hpux10
+For hpux10.20, we @emph{highly} recommend you pick up the latest sed patch
+@code{PHCO_19798} from HP@.
+
+The C++ ABI has changed incompatibly in GCC 4.0.  COMDAT subspaces are
+used for one-only code and data.  This resolves many of the previous
+problems in using C++ on this target.  However, the ABI is not compatible
+with the one implemented under HP-UX 11 using secondary definitions.
+
+@html
+<hr />
+@end html
+@anchor{hppa-hp-hpux11}
+@heading hppa*-hp-hpux11
+GCC 3.0 and up support HP-UX 11.  GCC 2.95.x is not supported and cannot
+be used to compile GCC 3.0 and up.
+
+The libffi and libjava libraries haven't been ported to 64-bit HP-UX@
+and don't build.
+
+Refer to @uref{binaries.html,,binaries} for information about obtaining
+precompiled GCC binaries for HP-UX@.  Precompiled binaries must be obtained
+to build the Ada language as it can't be bootstrapped using C@.  Ada is
+only available for the 32-bit PA-RISC runtime.
+
+Starting with GCC 3.4 an ISO C compiler is required to bootstrap.  The
+bundled compiler supports only traditional C; you will need either HP's
+unbundled compiler, or a binary distribution of GCC@.
+
+It is possible to build GCC 3.3 starting with the bundled HP compiler,
+but the process requires several steps.  GCC 3.3 can then be used to
+build later versions.  The fastjar program contains ISO C code and
+can't be built with the HP bundled compiler.  This problem can be
+avoided by not building the Java language.  For example, use the
+@option{--enable-languages="c,c++,f77,objc"} option in your configure
+command.
+
+There are several possible approaches to building the distribution.
+Binutils can be built first using the HP tools.  Then, the GCC
+distribution can be built.  The second approach is to build GCC
+first using the HP tools, then build binutils, then rebuild GCC@.
+There have been problems with various binary distributions, so it
+is best not to start from a binary distribution.
+
+On 64-bit capable systems, there are two distinct targets.  Different
+installation prefixes must be used if both are to be installed on
+the same system.  The @samp{hppa[1-2]*-hp-hpux11*} target generates code
+for the 32-bit PA-RISC runtime architecture and uses the HP linker.
+The @samp{hppa64-hp-hpux11*} target generates 64-bit code for the
+PA-RISC 2.0 architecture.
+
+The script config.guess now selects the target type based on the compiler
+detected during configuration.  You must define @env{PATH} or @env{CC} so
+that configure finds an appropriate compiler for the initial bootstrap.
+When @env{CC} is used, the definition should contain the options that are
+needed whenever @env{CC} is used.
+
+Specifically, options that determine the runtime architecture must be
+in @env{CC} to correctly select the target for the build.  It is also
+convenient to place many other compiler options in @env{CC}.  For example,
+@env{CC="cc -Ac +DA2.0W -Wp,-H16376 -D_CLASSIC_TYPES -D_HPUX_SOURCE"}
+can be used to bootstrap the GCC 3.3 branch with the HP compiler in
+64-bit K&R/bundled mode.  The @option{+DA2.0W} option will result in
+the automatic selection of the @samp{hppa64-hp-hpux11*} target.  The
+macro definition table of cpp needs to be increased for a successful
+build with the HP compiler.  _CLASSIC_TYPES and _HPUX_SOURCE need to
+be defined when building with the bundled compiler, or when using the
+@option{-Ac} option.  These defines aren't necessary with @option{-Ae}.
+
+It is best to explicitly configure the @samp{hppa64-hp-hpux11*} target
+with the @option{--with-ld=@dots{}} option.  This overrides the standard
+search for ld.  The two linkers supported on this target require different
+commands.  The default linker is determined during configuration.  As a
+result, it's not possible to switch linkers in the middle of a GCC build.
+This has been reported to sometimes occur in unified builds of binutils
+and GCC@.
+
+A recent linker patch must be installed for the correct operation of
+GCC 3.3 and later.  @code{PHSS_26559} and @code{PHSS_24304} are the
+oldest linker patches that are known to work.  They are for HP-UX
+11.00 and 11.11, respectively.  @code{PHSS_24303}, the companion to
+@code{PHSS_24304}, might be usable but it hasn't been tested.  These
+patches have been superseded.  Consult the HP patch database to obtain
+the currently recommended linker patch for your system.
+
+The patches are necessary for the support of weak symbols on the
+32-bit port, and for the running of initializers and finalizers.  Weak
+symbols are implemented using SOM secondary definition symbols.  Prior
+to HP-UX 11, there are bugs in the linker support for secondary symbols.
+The patches correct a problem of linker core dumps creating shared
+libraries containing secondary symbols, as well as various other
+linking issues involving secondary symbols.
+
+GCC 3.3 uses the ELF DT_INIT_ARRAY and DT_FINI_ARRAY capabilities to
+run initializers and finalizers on the 64-bit port.  The 32-bit port
+uses the linker @option{+init} and @option{+fini} options for the same
+purpose.  The patches correct various problems with the +init/+fini
+options, including program core dumps.  Binutils 2.14 corrects a
+problem on the 64-bit port resulting from HP's non-standard use of
+the .init and .fini sections for array initializers and finalizers.
+
+Although the HP and GNU linkers are both supported for the
+@samp{hppa64-hp-hpux11*} target, it is strongly recommended that the
+HP linker be used for link editing on this target.
+
+At this time, the GNU linker does not support the creation of long
+branch stubs.  As a result, it can't successfully link binaries
+containing branch offsets larger than 8 megabytes.  In addition,
+there are problems linking shared libraries, linking executables
+with @option{-static}, and with dwarf2 unwind and exception support.
+It also doesn't provide stubs for internal calls to global functions
+in shared libraries, so these calls can't be overloaded.
+
+The HP dynamic loader does not support GNU symbol versioning, so symbol
+versioning is not supported.  It may be necessary to disable symbol
+versioning with @option{--disable-symvers} when using GNU ld.
+
+POSIX threads are the default.  The optional DCE thread library is not
+supported, so @option{--enable-threads=dce} does not work.
+
+@html
+<hr />
+@end html
+@anchor{x-x-linux-gnu}
+@heading *-*-linux-gnu
+Versions of libstdc++-v3 starting with 3.2.1 require bug fixes present
+in glibc 2.2.5 and later.  More information is available in the
+libstdc++-v3 documentation.
+
+@html
+<hr />
+@end html
+@anchor{ix86-x-linux}
+@heading i?86-*-linux*
+As of GCC 3.3, binutils 2.13.1 or later is required for this platform.
+See @uref{http://gcc.gnu.org/PR10877,,bug 10877} for more information.
+
+If you receive Signal 11 errors when building on GNU/Linux, then it is
+possible you have a hardware problem.  Further information on this can be
+found on @uref{http://www.bitwizard.nl/sig11/,,www.bitwizard.nl}.
+
+@html
+<hr />
+@end html
+@anchor{ix86-x-solaris29}
+@heading i?86-*-solaris2.9
+The Sun assembler in Solaris 9 has several bugs and limitations.
+While GCC works around them, several features are missing, so it is
+@c FIXME: which ones?
+recommended to use the GNU assembler instead.  There is no bundled
+version, but the current version, from GNU binutils 2.22, is known to
+work.
+
+Solaris@tie{}2/x86 doesn't support the execution of SSE/SSE2 instructions
+before Solaris@tie{}9 4/04, even if the CPU supports them.  Programs will
+receive @code{SIGILL} if they try.  The fix is available both in
+Solaris@tie{}9 Update@tie{}6 and kernel patch 112234-12 or newer.  To
+avoid this problem,
+@option{-march} defaults to @samp{pentiumpro} on Solaris 9.  If
+you have the patch installed, you can configure GCC with an appropriate
+@option{--with-arch} option, but need GNU @command{as} for SSE2 support.
+
+@html
+<hr />
+@end html
+@anchor{ix86-x-solaris210}
+@heading i?86-*-solaris2.10
+Use this for Solaris 10 or later on x86 and x86-64 systems.  Starting
+with GCC 4.7, there is also a 64-bit @samp{amd64-*-solaris2.1[0-9]*} or
+@samp{x86_64-*-solaris2.1[0-9]*} configuration that corresponds to
+@samp{sparcv9-sun-solaris2*}.
+
+It is recommended that you configure GCC to use the GNU assembler, in
+@file{/usr/sfw/bin/gas}.  The versions included in Solaris 10, from GNU
+binutils 2.15, and Solaris 11, from GNU binutils 2.19, work fine,
+although the current version, from GNU binutils
+2.22, is known to work, too.  Recent versions of the Sun assembler in
+@file{/usr/ccs/bin/as} work almost as well, though.
+@c FIXME: as patch requirements?
+
+For linking, the Sun linker, is preferred.  If you want to use the GNU
+linker instead, which is available in @file{/usr/sfw/bin/gld}, note that
+due to a packaging bug the version in Solaris 10, from GNU binutils
+2.15, cannot be used, while the version in Solaris 11, from GNU binutils
+2.19, works, as does the latest version, from GNU binutils 2.22.
+
+To use GNU @command{as}, configure with the options
+@option{--with-gnu-as --with-as=@//usr/@/sfw/@/bin/@/gas}.  It may be necessary
+to configure with @option{--without-gnu-ld --with-ld=@//usr/@/ccs/@/bin/@/ld} to
+guarantee use of Sun @command{ld}.
+@c FIXME: why --without-gnu-ld --with-ld?
+
+@html
+<hr />
+@end html
+@anchor{ia64-x-linux}
+@heading ia64-*-linux
+IA-64 processor (also known as IPF, or Itanium Processor Family)
+running GNU/Linux.
+
+If you are using the installed system libunwind library with
+@option{--with-system-libunwind}, then you must use libunwind 0.98 or
+later.
+
+None of the following versions of GCC has an ABI that is compatible
+with any of the other versions in this list, with the exception that
+Red Hat 2.96 and Trillian 000171 are compatible with each other:
+3.1, 3.0.2, 3.0.1, 3.0, Red Hat 2.96, and Trillian 000717.
+This primarily affects C++ programs and programs that create shared libraries.
+GCC 3.1 or later is recommended for compiling linux, the kernel.
+As of version 3.1 GCC is believed to be fully ABI compliant, and hence no
+more major ABI changes are expected.
+
+@html
+<hr />
+@end html
+@anchor{ia64-x-hpux}
+@heading ia64-*-hpux*
+Building GCC on this target requires the GNU Assembler.  The bundled HP
+assembler will not work.  To prevent GCC from using the wrong assembler,
+the option @option{--with-gnu-as} may be necessary.
+
+The GCC libunwind library has not been ported to HPUX@.  This means that for
+GCC versions 3.2.3 and earlier, @option{--enable-libunwind-exceptions}
+is required to build GCC@.  For GCC 3.3 and later, this is the default.
+For gcc 3.4.3 and later, @option{--enable-libunwind-exceptions} is
+removed and the system libunwind library will always be used.
+
+@html
+<hr />
+@end html
+@anchor{aarch64-x-x}
+@heading aarch64*-*-*
+Pre 2.24 binutils does not have support for selecting -mabi and does not
+support ILP32.  If GCC 4.9 or later is built with pre 2.24, GCC will not
+support option -mabi=ilp32.
+
+@html
+<hr />
+<!-- rs6000-ibm-aix*, powerpc-ibm-aix* -->
+@end html
+@anchor{x-ibm-aix}
+@heading *-ibm-aix*
+Support for AIX version 3 and older was discontinued in GCC 3.4.
+Support for AIX version 4.2 and older was discontinued in GCC 4.5.
+
+``out of memory'' bootstrap failures may indicate a problem with
+process resource limits (ulimit).  Hard limits are configured in the
+@file{/etc/security/limits} system configuration file.
+
+GCC can bootstrap with recent versions of IBM XLC, but bootstrapping
+with an earlier release of GCC is recommended.  Bootstrapping with XLC
+requires a larger data segment, which can be enabled through the
+@var{LDR_CNTRL} environment variable, e.g.,
+
+@smallexample
+% LDR_CNTRL=MAXDATA=0x50000000
+% export LDR_CNTRL
+@end smallexample
+
+One can start with a pre-compiled version of GCC to build from
+sources.  One may delete GCC's ``fixed'' header files when starting
+with a version of GCC built for an earlier release of AIX.
+
+To speed up the configuration phases of bootstrapping and installing GCC,
+one may use GNU Bash instead of AIX @command{/bin/sh}, e.g.,
+
+@smallexample
+% CONFIG_SHELL=/opt/freeware/bin/bash
+% export CONFIG_SHELL
+@end smallexample
+
+and then proceed as described in @uref{build.html,,the build
+instructions}, where we strongly recommend specifying an absolute path
+to invoke @var{srcdir}/configure.
+
+Because GCC on AIX is built as a 32-bit executable by default,
+(although it can generate 64-bit programs) the GMP and MPFR libraries
+required by gfortran must be 32-bit libraries.  Building GMP and MPFR
+as static archive libraries works better than shared libraries.
+
+Errors involving @code{alloca} when building GCC generally are due
+to an incorrect definition of @code{CC} in the Makefile or mixing files
+compiled with the native C compiler and GCC@.  During the stage1 phase of
+the build, the native AIX compiler @strong{must} be invoked as @command{cc}
+(not @command{xlc}).  Once @command{configure} has been informed of
+@command{xlc}, one needs to use @samp{make distclean} to remove the
+configure cache files and ensure that @env{CC} environment variable
+does not provide a definition that will confuse @command{configure}.
+If this error occurs during stage2 or later, then the problem most likely
+is the version of Make (see above).
+
+The native @command{as} and @command{ld} are recommended for
+bootstrapping on AIX@.  The GNU Assembler, GNU Linker, and GNU
+Binutils version 2.20 is the minimum level that supports bootstrap on
+AIX 5@.  The GNU Assembler has not been updated to support AIX 6@ or
+AIX 7.  The native AIX tools do interoperate with GCC@.
+
+AIX 5.3 TL10, AIX 6.1 TL05 and AIX 7.1 TL00 introduced an AIX
+assembler change that sometimes produces corrupt assembly files
+causing AIX linker errors.  The bug breaks GCC bootstrap on AIX and
+can cause compilation failures with existing GCC installations.  An
+AIX iFix for AIX 5.3 is available (APAR IZ98385 for AIX 5.3 TL10, APAR
+IZ98477 for AIX 5.3 TL11 and IZ98134 for AIX 5.3 TL12). AIX 5.3 TL11 SP8,
+AIX 5.3 TL12 SP5, AIX 6.1 TL04 SP11, AIX 6.1 TL05 SP7, AIX 6.1 TL06 SP6,
+AIX 6.1 TL07 and AIX 7.1 TL01 should include the fix.
+
+Building @file{libstdc++.a} requires a fix for an AIX Assembler bug
+APAR IY26685 (AIX 4.3) or APAR IY25528 (AIX 5.1).  It also requires a
+fix for another AIX Assembler bug and a co-dependent AIX Archiver fix
+referenced as APAR IY53606 (AIX 5.2) or as APAR IY54774 (AIX 5.1)
+
+@samp{libstdc++} in GCC 3.4 increments the major version number of the
+shared object and GCC installation places the @file{libstdc++.a}
+shared library in a common location which will overwrite the and GCC
+3.3 version of the shared library.  Applications either need to be
+re-linked against the new shared library or the GCC 3.1 and GCC 3.3
+versions of the @samp{libstdc++} shared object needs to be available
+to the AIX runtime loader.  The GCC 3.1 @samp{libstdc++.so.4}, if
+present, and GCC 3.3 @samp{libstdc++.so.5} shared objects can be
+installed for runtime dynamic loading using the following steps to set
+the @samp{F_LOADONLY} flag in the shared object for @emph{each}
+multilib @file{libstdc++.a} installed:
+
+Extract the shared objects from the currently installed
+@file{libstdc++.a} archive:
+@smallexample
+% ar -x libstdc++.a libstdc++.so.4 libstdc++.so.5
+@end smallexample
+
+Enable the @samp{F_LOADONLY} flag so that the shared object will be
+available for runtime dynamic loading, but not linking:
+@smallexample
+% strip -e libstdc++.so.4 libstdc++.so.5
+@end smallexample
+
+Archive the runtime-only shared object in the GCC 3.4
+@file{libstdc++.a} archive:
+@smallexample
+% ar -q libstdc++.a libstdc++.so.4 libstdc++.so.5
+@end smallexample
+
+Linking executables and shared libraries may produce warnings of
+duplicate symbols.  The assembly files generated by GCC for AIX always
+have included multiple symbol definitions for certain global variable
+and function declarations in the original program.  The warnings should
+not prevent the linker from producing a correct library or runnable
+executable.
+
+AIX 4.3 utilizes a ``large format'' archive to support both 32-bit and
+64-bit object modules.  The routines provided in AIX 4.3.0 and AIX 4.3.1
+to parse archive libraries did not handle the new format correctly.
+These routines are used by GCC and result in error messages during
+linking such as ``not a COFF file''.  The version of the routines shipped
+with AIX 4.3.1 should work for a 32-bit environment.  The @option{-g}
+option of the archive command may be used to create archives of 32-bit
+objects using the original ``small format''.  A correct version of the
+routines is shipped with AIX 4.3.2 and above.
+
+Some versions of the AIX binder (linker) can fail with a relocation
+overflow severe error when the @option{-bbigtoc} option is used to link
+GCC-produced object files into an executable that overflows the TOC@.  A fix
+for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is
+available from IBM Customer Support and from its
+@uref{http://techsupport.services.ibm.com/,,techsupport.services.ibm.com}
+website as PTF U455193.
+
+The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core
+with a segmentation fault when invoked by any version of GCC@.  A fix for
+APAR IX87327 is available from IBM Customer Support and from its
+@uref{http://techsupport.services.ibm.com/,,techsupport.services.ibm.com}
+website as PTF U461879.  This fix is incorporated in AIX 4.3.3 and above.
+
+The initial assembler shipped with AIX 4.3.0 generates incorrect object
+files.  A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS
+TO ASSEMBLE/BIND) is available from IBM Customer Support and from its
+@uref{http://techsupport.services.ibm.com/,,techsupport.services.ibm.com}
+website as PTF U453956.  This fix is incorporated in AIX 4.3.1 and above.
+
+AIX provides National Language Support (NLS)@.  Compilers and assemblers
+use NLS to support locale-specific representations of various data
+formats including floating-point numbers (e.g., @samp{.}  vs @samp{,} for
+separating decimal fractions).  There have been problems reported where
+GCC does not produce the same floating-point formats that the assembler
+expects.  If one encounters this problem, set the @env{LANG}
+environment variable to @samp{C} or @samp{En_US}.
+
+A default can be specified with the @option{-mcpu=@var{cpu_type}}
+switch and using the configure option @option{--with-cpu-@var{cpu_type}}.
+
+@html
+<hr />
+@end html
+@anchor{iq2000-x-elf}
+@heading iq2000-*-elf
+Vitesse IQ2000 processors.  These are used in embedded
+applications.  There are no standard Unix configurations.
+
+@html
+<hr />
+@end html
+@anchor{lm32-x-elf}
+@heading lm32-*-elf
+Lattice Mico32 processor.
+This configuration is intended for embedded systems.
+
+@html
+<hr />
+@end html
+@anchor{lm32-x-uclinux}
+@heading lm32-*-uclinux
+Lattice Mico32 processor.
+This configuration is intended for embedded systems running uClinux.
+
+@html
+<hr />
+@end html
+@anchor{m32c-x-elf}
+@heading m32c-*-elf
+Renesas M32C processor.
+This configuration is intended for embedded systems.
+
+@html
+<hr />
+@end html
+@anchor{m32r-x-elf}
+@heading m32r-*-elf
+Renesas M32R processor.
+This configuration is intended for embedded systems.
+
+@html
+<hr />
+@end html
+@anchor{m68k-x-x}
+@heading m68k-*-*
+By default,
+@samp{m68k-*-elf*}, @samp{m68k-*-rtems},  @samp{m68k-*-uclinux} and
+@samp{m68k-*-linux}
+build libraries for both M680x0 and ColdFire processors.  If you only
+need the M680x0 libraries, you can omit the ColdFire ones by passing
+@option{--with-arch=m68k} to @command{configure}.  Alternatively, you
+can omit the M680x0 libraries by passing @option{--with-arch=cf} to
+@command{configure}.  These targets default to 5206 or 5475 code as
+appropriate for the target system when
+configured with @option{--with-arch=cf} and 68020 code otherwise.
+
+The @samp{m68k-*-netbsd} and
+@samp{m68k-*-openbsd} targets also support the @option{--with-arch}
+option.  They will generate ColdFire CFV4e code when configured with
+@option{--with-arch=cf} and 68020 code otherwise.
+
+You can override the default processors listed above by configuring
+with @option{--with-cpu=@var{target}}.  This @var{target} can either
+be a @option{-mcpu} argument or one of the following values:
+@samp{m68000}, @samp{m68010}, @samp{m68020}, @samp{m68030},
+@samp{m68040}, @samp{m68060}, @samp{m68020-40} and @samp{m68020-60}.
+
+GCC requires at least binutils version 2.17 on these targets.
+
+@html
+<hr />
+@end html
+@anchor{m68k-x-uclinux}
+@heading m68k-*-uclinux
+GCC 4.3 changed the uClinux configuration so that it uses the
+@samp{m68k-linux-gnu} ABI rather than the @samp{m68k-elf} ABI.
+It also added improved support for C++ and flat shared libraries,
+both of which were ABI changes.
+
+@html
+<hr />
+@end html
+@anchor{mep-x-elf}
+@heading mep-*-elf
+Toshiba Media embedded Processor.
+This configuration is intended for embedded systems.
+
+@html
+<hr />
+@end html
+@anchor{microblaze-x-elf}
+@heading microblaze-*-elf
+Xilinx MicroBlaze processor.
+This configuration is intended for embedded systems.
+
+@html
+<hr />
+@end html
+@anchor{mips-x-x}
+@heading mips-*-*
+If on a MIPS system you get an error message saying ``does not have gp
+sections for all it's [sic] sectons [sic]'', don't worry about it.  This
+happens whenever you use GAS with the MIPS linker, but there is not
+really anything wrong, and it is okay to use the output file.  You can
+stop such warnings by installing the GNU linker.
+
+It would be nice to extend GAS to produce the gp tables, but they are
+optional, and there should not be a warning about their absence.
+
+The libstdc++ atomic locking routines for MIPS targets requires MIPS II
+and later.  A patch went in just after the GCC 3.3 release to
+make @samp{mips*-*-*} use the generic implementation instead.  You can also
+configure for @samp{mipsel-elf} as a workaround.  The
+@samp{mips*-*-linux*} target continues to use the MIPS II routines.  More
+work on this is expected in future releases.
+
+@c If you make --with-llsc the default for another target, please also
+@c update the description of the --with-llsc option.
+
+The built-in @code{__sync_*} functions are available on MIPS II and
+later systems and others that support the @samp{ll}, @samp{sc} and
+@samp{sync} instructions.  This can be overridden by passing
+@option{--with-llsc} or @option{--without-llsc} when configuring GCC.
+Since the Linux kernel emulates these instructions if they are
+missing, the default for @samp{mips*-*-linux*} targets is
+@option{--with-llsc}.  The @option{--with-llsc} and
+@option{--without-llsc} configure options may be overridden at compile
+time by passing the @option{-mllsc} or @option{-mno-llsc} options to
+the compiler.
+
+MIPS systems check for division by zero (unless
+@option{-mno-check-zero-division} is passed to the compiler) by
+generating either a conditional trap or a break instruction.  Using
+trap results in smaller code, but is only supported on MIPS II and
+later.  Also, some versions of the Linux kernel have a bug that
+prevents trap from generating the proper signal (@code{SIGFPE}).  To enable
+the use of break, use the @option{--with-divide=breaks}
+@command{configure} option when configuring GCC@.  The default is to
+use traps on systems that support them.
+
+The assembler from GNU binutils 2.17 and earlier has a bug in the way
+it sorts relocations for REL targets (o32, o64, EABI).  This can cause
+bad code to be generated for simple C++ programs.  Also the linker
+from GNU binutils versions prior to 2.17 has a bug which causes the
+runtime linker stubs in very large programs, like @file{libgcj.so}, to
+be incorrectly generated.  GNU Binutils 2.18 and later (and snapshots
+made after Nov. 9, 2006) should be free from both of these problems.
+
+@html
+<hr />
+@end html
+@anchor{mips-sgi-irix5}
+@heading mips-sgi-irix5
+Support for IRIX 5 has been removed in GCC 4.6.
+
+@html
+<hr />
+@end html
+@anchor{mips-sgi-irix6}
+@heading mips-sgi-irix6
+Support for IRIX 6.5 has been removed in GCC 4.8.  Support for IRIX 6
+releases before 6.5 has been removed in GCC 4.6, as well as support for
+the O32 ABI.
+
+@html
+<hr />
+@end html
+@anchor{moxie-x-elf}
+@heading moxie-*-elf
+The moxie processor.
+
+@html
+<hr />
+@end html
+@anchor{msp430-x-elf}
+@heading msp430-*-elf
+TI MSP430 processor.
+This configuration is intended for embedded systems.
+
+@html
+<hr />
+@end html
+@anchor{powerpc-x-x}
+@heading powerpc-*-*
+You can specify a default version for the @option{-mcpu=@var{cpu_type}}
+switch by using the configure option @option{--with-cpu-@var{cpu_type}}.
+
+You will need
+@uref{ftp://ftp.kernel.org/pub/linux/devel/binutils,,binutils 2.15}
+or newer for a working GCC@.
+
+@html
+<hr />
+@end html
+@anchor{powerpc-x-darwin}
+@heading powerpc-*-darwin*
+PowerPC running Darwin (Mac OS X kernel).
+
+Pre-installed versions of Mac OS X may not include any developer tools,
+meaning that you will not be able to build GCC from source.  Tool
+binaries are available at
+@uref{http://opensource.apple.com/}.
+
+This version of GCC requires at least cctools-590.36.  The
+cctools-590.36 package referenced from
+@uref{http://gcc.gnu.org/ml/gcc/2006-03/msg00507.html} will not work
+on systems older than 10.3.9 (aka darwin7.9.0).
+
+@html
+<hr />
+@end html
+@anchor{powerpc-x-elf}
+@heading powerpc-*-elf
+PowerPC system in big endian mode, running System V.4.
+
+@html
+<hr />
+@end html
+@anchor{powerpc-x-linux-gnu}
+@heading powerpc*-*-linux-gnu*
+PowerPC system in big endian mode running Linux.
+
+@html
+<hr />
+@end html
+@anchor{powerpc-x-netbsd}
+@heading powerpc-*-netbsd*
+PowerPC system in big endian mode running NetBSD@.
+
+@html
+<hr />
+@end html
+@anchor{powerpc-x-eabisim}
+@heading powerpc-*-eabisim
+Embedded PowerPC system in big endian mode for use in running under the
+PSIM simulator.
+
+@html
+<hr />
+@end html
+@anchor{powerpc-x-eabi}
+@heading powerpc-*-eabi
+Embedded PowerPC system in big endian mode.
+
+@html
+<hr />
+@end html
+@anchor{powerpcle-x-elf}
+@heading powerpcle-*-elf
+PowerPC system in little endian mode, running System V.4.
+
+@html
+<hr />
+@end html
+@anchor{powerpcle-x-eabisim}
+@heading powerpcle-*-eabisim
+Embedded PowerPC system in little endian mode for use in running under
+the PSIM simulator.
+
+@html
+<hr />
+@end html
+@anchor{powerpcle-x-eabi}
+@heading powerpcle-*-eabi
+Embedded PowerPC system in little endian mode.
+
+@html
+<hr />
+@end html
+@anchor{rl78-x-elf}
+@heading rl78-*-elf
+The Renesas RL78 processor.
+This configuration is intended for embedded systems.
+
+@html
+<hr />
+@end html
+@anchor{rx-x-elf}
+@heading rx-*-elf
+The Renesas RX processor.  See
+@uref{http://eu.renesas.com/fmwk.jsp?cnt=rx600_series_landing.jsp&fp=/products/mpumcu/rx_family/rx600_series}
+for more information about this processor.
+
+@html
+<hr />
+@end html
+@anchor{s390-x-linux}
+@heading s390-*-linux*
+S/390 system running GNU/Linux for S/390@.
+
+@html
+<hr />
+@end html
+@anchor{s390x-x-linux}
+@heading s390x-*-linux*
+zSeries system (64-bit) running GNU/Linux for zSeries@.
+
+@html
+<hr />
+@end html
+@anchor{s390x-ibm-tpf}
+@heading s390x-ibm-tpf*
+zSeries system (64-bit) running TPF@.  This platform is
+supported as cross-compilation target only.
+
+@html
+<hr />
+@end html
+@c Please use Solaris 2 to refer to all release of Solaris, starting
+@c with 2.0 until 2.6, 7, 8, etc.  Solaris 1 was a marketing name for
+@c SunOS 4 releases which we don't use to avoid confusion.  Solaris
+@c alone is too unspecific and must be avoided.
+@anchor{x-x-solaris2}
+@heading *-*-solaris2*
+Support for Solaris 9 has been obsoleted in GCC 4.9, but can still be
+enabled by configuring with @option{--enable-obsolete}.  Support will be
+removed in GCC 4.10.  Support for Solaris 8 has removed in GCC 4.8.
+Support for Solaris 7 has been removed in GCC 4.6.
+
+Sun does not ship a C compiler with Solaris 2 before Solaris 10, though
+you can download the Sun Studio compilers for free.  In Solaris 10 and
+11, GCC 3.4.3 is available as @command{/usr/sfw/bin/gcc}.  Solaris 11
+also provides GCC 4.5.2 as @command{/usr/gcc/4.5/bin/gcc}.  Alternatively,
+you can install a pre-built GCC to bootstrap and install GCC.  See the
+@uref{binaries.html,,binaries page} for details.
+
+The Solaris 2 @command{/bin/sh} will often fail to configure
+@samp{libstdc++-v3}, @samp{boehm-gc} or @samp{libjava}.  We therefore
+recommend using the following initial sequence of commands
+
+@smallexample
+% CONFIG_SHELL=/bin/ksh
+% export CONFIG_SHELL
+@end smallexample
+
+@noindent
+and proceed as described in @uref{configure.html,,the configure instructions}.
+In addition we strongly recommend specifying an absolute path to invoke
+@command{@var{srcdir}/configure}.
+
+Solaris 2 comes with a number of optional OS packages.  Some of these
+are needed to use GCC fully, namely @code{SUNWarc},
+@code{SUNWbtool}, @code{SUNWesu}, @code{SUNWhea}, @code{SUNWlibm},
+@code{SUNWsprot}, and @code{SUNWtoo}.  If you did not install all
+optional packages when installing Solaris 2, you will need to verify that
+the packages that GCC needs are installed.
+
+To check whether an optional package is installed, use
+the @command{pkginfo} command.  To add an optional package, use the
+@command{pkgadd} command.  For further details, see the Solaris 2
+documentation.
+
+Trying to use the linker and other tools in
+@file{/usr/ucb} to install GCC has been observed to cause trouble.
+For example, the linker may hang indefinitely.  The fix is to remove
+@file{/usr/ucb} from your @env{PATH}.
+
+The build process works more smoothly with the legacy Sun tools so, if you
+have @file{/usr/xpg4/bin} in your @env{PATH}, we recommend that you place
+@file{/usr/bin} before @file{/usr/xpg4/bin} for the duration of the build.
+
+We recommend the use of the Sun assembler or the GNU assembler, in
+conjunction with the Sun linker.  The GNU @command{as}
+versions included in Solaris 10, from GNU binutils 2.15, and Solaris 11,
+from GNU binutils 2.19, are known to work.  They can be found in
+@file{/usr/sfw/bin/gas}.  Current versions of GNU binutils (2.22)
+are known to work as well.  Note that your mileage may vary
+if you use a combination of the GNU tools and the Sun tools: while the
+combination GNU @command{as} + Sun @command{ld} should reasonably work,
+the reverse combination Sun @command{as} + GNU @command{ld} may fail to
+build or cause memory corruption at runtime in some cases for C++ programs.
+@c FIXME: still?
+GNU @command{ld} usually works as well, although the version included in
+Solaris 10 cannot be used due to several bugs.  Again, the current
+version (2.22) is known to work, but generally lacks platform specific
+features, so better stay with Sun @command{ld}.  To use the LTO linker
+plugin (@option{-fuse-linker-plugin}) with GNU @command{ld}, GNU
+binutils @emph{must} be configured with @option{--enable-largefile}.
+
+To enable symbol versioning in @samp{libstdc++} with Sun @command{ld},
+you need to have any version of GNU @command{c++filt}, which is part of
+GNU binutils.  @samp{libstdc++} symbol versioning will be disabled if no
+appropriate version is found.  Sun @command{c++filt} from the Sun Studio
+compilers does @emph{not} work.
+
+Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or
+newer: @command{g++} will complain that types are missing.  These headers
+assume that omitting the type means @code{int}; this assumption worked for
+C90 but is wrong for C++, and is now wrong for C99 also.
+
+Sun bug 4927647 sometimes causes random spurious testsuite failures
+related to missing diagnostic output.  This bug doesn't affect GCC
+itself, rather it is a kernel bug triggered by the @command{expect}
+program which is used only by the GCC testsuite driver.  When the bug
+causes the @command{expect} program to miss anticipated output, extra
+testsuite failures appear.
+
+There are patches for Solaris 9 (117171-11 or newer for
+SPARC, 117172-11 or newer for Intel) that address this problem.
+
+Thread-local storage (TLS) is supported in Solaris@tie{}9, but requires
+some patches.  The @samp{libthread} patches provide the
+@code{__tls_get_addr} (SPARC, 64-bit x86) resp.@ @code{___tls_get_addr}
+(32-bit x86) functions.  On Solaris@tie{}9, the necessary support
+on SPARC is present since FCS, while 114432-05 or newer is required on
+Intel.  Additionally, on Solaris@tie{}9/x86, patch 113986-02 or newer is
+required for the Sun @command{ld} and runtime linker (@command{ld.so.1})
+support, while Solaris@tie{}9/SPARC works since FCS.  The linker
+patches must be installed even if GNU @command{ld} is used. Sun
+@command{as} in Solaris@tie{}9 doesn't support the necessary
+relocations, so GNU @command{as} must be used.  The @command{configure}
+script checks for those prerequisites and automatically enables TLS
+support if they are met.  Although those minimal patch versions should
+work, it is recommended to use the latest patch versions which include
+additional bug fixes.
+
+@html
+<hr />
+@end html
+@anchor{sparc-x-x}
+@heading sparc*-*-*
+This section contains general configuration information for all
+SPARC-based platforms.  In addition to reading this section, please
+read all other sections that match your target.
+
+Newer versions of the GNU Multiple Precision Library (GMP), the MPFR
+library and the MPC library are known to be miscompiled by earlier
+versions of GCC on these platforms.  We therefore recommend the use
+of the exact versions of these libraries listed as minimal versions
+in @uref{prerequisites.html,,the prerequisites}.
+
+@html
+<hr />
+@end html
+@anchor{sparc-sun-solaris2}
+@heading sparc-sun-solaris2*
+When GCC is configured to use GNU binutils 2.14 or later, the binaries
+produced are smaller than the ones produced using Sun's native tools;
+this difference is quite significant for binaries containing debugging
+information.
+
+Starting with Solaris 7, the operating system is capable of executing
+64-bit SPARC V9 binaries.  GCC 3.1 and later properly supports
+this; the @option{-m64} option enables 64-bit code generation.
+However, if all you want is code tuned for the UltraSPARC CPU, you
+should try the @option{-mtune=ultrasparc} option instead, which produces
+code that, unlike full 64-bit code, can still run on non-UltraSPARC
+machines.
+
+When configuring on a Solaris 7 or later system that is running a kernel
+that supports only 32-bit binaries, one must configure with
+@option{--disable-multilib}, since we will not be able to build the
+64-bit target libraries.
+
+GCC 3.3 and GCC 3.4 trigger code generation bugs in earlier versions of
+the GNU compiler (especially GCC 3.0.x versions), which lead to the
+miscompilation of the stage1 compiler and the subsequent failure of the
+bootstrap process.  A workaround is to use GCC 3.2.3 as an intermediary
+stage, i.e.@: to bootstrap that compiler with the base compiler and then
+use it to bootstrap the final compiler.
+
+GCC 3.4 triggers a code generation bug in versions 5.4 (Sun ONE Studio 7)
+and 5.5 (Sun ONE Studio 8) of the Sun compiler, which causes a bootstrap
+failure in form of a miscompilation of the stage1 compiler by the Sun
+compiler.  This is Sun bug 4974440.  This is fixed with patch 112760-07.
+
+GCC 3.4 changed the default debugging format from Stabs to DWARF-2 for
+32-bit code on Solaris 7 and later.  If you use the Sun assembler, this
+change apparently runs afoul of Sun bug 4910101 (which is referenced as
+an x86-only problem by Sun, probably because they do not use DWARF-2).
+A symptom of the problem is that you cannot compile C++ programs like
+@command{groff} 1.19.1 without getting messages similar to the following:
+
+@smallexample
+ld: warning: relocation error: R_SPARC_UA32: @dots{}
+  external symbolic relocation against non-allocatable section
+  .debug_info cannot be processed at runtime: relocation ignored.
+@end smallexample
+
+@noindent
+To work around this problem, compile with @option{-gstabs+} instead of
+plain @option{-g}.
+
+When configuring the GNU Multiple Precision Library (GMP), the MPFR
+library or the MPC library on a Solaris 7 or later system, the canonical
+target triplet must be specified as the @command{build} parameter on the
+configure line.  This target triplet can be obtained by invoking @command{./config.guess} in the toplevel source directory of GCC (and
+not that of GMP or MPFR or MPC).  For example on a Solaris 9 system:
+
+@smallexample
+% ./configure --build=sparc-sun-solaris2.9 --prefix=xxx
+@end smallexample
+
+@html
+<hr />
+@end html
+@anchor{sparc-sun-solaris210}
+@heading sparc-sun-solaris2.10
+There is a bug in older versions of the Sun assembler which breaks
+thread-local storage (TLS).  A typical error message is
+
+@smallexample
+ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file /var/tmp//ccamPA1v.o:
+  symbol <unknown>: bad symbol type SECT: symbol type must be TLS
+@end smallexample
+
+@noindent
+This bug is fixed in Sun patch 118683-03 or later.
+
+@html
+<hr />
+@end html
+@anchor{sparc-x-linux}
+@heading sparc-*-linux*
+
+GCC versions 3.0 and higher require binutils 2.11.2 and glibc 2.2.4
+or newer on this platform.  All earlier binutils and glibc
+releases mishandled unaligned relocations on @code{sparc-*-*} targets.
+
+
+@html
+<hr />
+@end html
+@anchor{sparc64-x-solaris2}
+@heading sparc64-*-solaris2*
+When configuring the GNU Multiple Precision Library (GMP), the MPFR
+library or the MPC library, the canonical target triplet must be specified
+as the @command{build} parameter on the configure line.  For example
+on a Solaris 9 system:
+
+@smallexample
+% ./configure --build=sparc64-sun-solaris2.9 --prefix=xxx
+@end smallexample
+
+The following compiler flags must be specified in the configure
+step in order to bootstrap this target with the Sun compiler:
+
+@smallexample
+% CC="cc -xarch=v9 -xildoff" @var{srcdir}/configure [@var{options}] [@var{target}]
+@end smallexample
+
+@noindent
+@option{-xarch=v9} specifies the SPARC-V9 architecture to the Sun toolchain
+and @option{-xildoff} turns off the incremental linker.
+
+@html
+<hr />
+@end html
+@anchor{sparcv9-x-solaris2}
+@heading sparcv9-*-solaris2*
+This is a synonym for @samp{sparc64-*-solaris2*}.
+
+@html
+<hr />
+@end html
+@anchor{c6x-x-x}
+@heading c6x-*-*
+The C6X family of processors. This port requires binutils-2.22 or newer.
+
+@html
+<hr />
+@end html
+@anchor{tilegx-*-linux}
+@heading tilegx-*-linux*
+The TILE-Gx processor in little endian mode, running GNU/Linux.  This
+port requires binutils-2.22 or newer.
+
+@html
+<hr />
+@end html
+@anchor{tilegxbe-*-linux}
+@heading tilegxbe-*-linux*
+The TILE-Gx processor in big endian mode, running GNU/Linux.  This
+port requires binutils-2.23 or newer.
+
+@html
+<hr />
+@end html
+@anchor{tilepro-*-linux}
+@heading tilepro-*-linux*
+The TILEPro processor running GNU/Linux.  This port requires
+binutils-2.22 or newer.
+
+@html
+<hr />
+@end html
+@anchor{x-x-vxworks}
+@heading *-*-vxworks*
+Support for VxWorks is in flux.  At present GCC supports @emph{only} the
+very recent VxWorks 5.5 (aka Tornado 2.2) release, and only on PowerPC@.
+We welcome patches for other architectures supported by VxWorks 5.5.
+Support for VxWorks AE would also be welcome; we believe this is merely
+a matter of writing an appropriate ``configlette'' (see below).  We are
+not interested in supporting older, a.out or COFF-based, versions of
+VxWorks in GCC 3.
+
+VxWorks comes with an older version of GCC installed in
+@file{@var{$WIND_BASE}/host}; we recommend you do not overwrite it.
+Choose an installation @var{prefix} entirely outside @var{$WIND_BASE}.
+Before running @command{configure}, create the directories @file{@var{prefix}}
+and @file{@var{prefix}/bin}.  Link or copy the appropriate assembler,
+linker, etc.@: into @file{@var{prefix}/bin}, and set your @var{PATH} to
+include that directory while running both @command{configure} and
+@command{make}.
+
+You must give @command{configure} the
+@option{--with-headers=@var{$WIND_BASE}/target/h} switch so that it can
+find the VxWorks system headers.  Since VxWorks is a cross compilation
+target only, you must also specify @option{--target=@var{target}}.
+@command{configure} will attempt to create the directory
+@file{@var{prefix}/@var{target}/sys-include} and copy files into it;
+make sure the user running @command{configure} has sufficient privilege
+to do so.
+
+GCC's exception handling runtime requires a special ``configlette''
+module, @file{contrib/gthr_supp_vxw_5x.c}.  Follow the instructions in
+that file to add the module to your kernel build.  (Future versions of
+VxWorks will incorporate this module.)
+
+@html
+<hr />
+@end html
+@anchor{x86-64-x-x}
+@heading x86_64-*-*, amd64-*-*
+GCC supports the x86-64 architecture implemented by the AMD64 processor
+(amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD@.
+On GNU/Linux the default is a bi-arch compiler which is able to generate
+both 64-bit x86-64 and 32-bit x86 code (via the @option{-m32} switch).
+
+@html
+<hr />
+@end html
+@anchor{x86-64-x-solaris210}
+@heading x86_64-*-solaris2.1[0-9]*
+GCC also supports the x86-64 architecture implemented by the AMD64
+processor (@samp{amd64-*-*} is an alias for @samp{x86_64-*-*}) on
+Solaris 10 or later.  Unlike other systems, without special options a
+bi-arch compiler is built which generates 32-bit code by default, but
+can generate 64-bit x86-64 code with the @option{-m64} switch.  Since
+GCC 4.7, there is also configuration that defaults to 64-bit code, but
+can generate 32-bit code with @option{-m32}.  To configure and build
+this way, you have to provide all support libraries like @file{libgmp}
+as 64-bit code, configure with @option{--target=x86_64-pc-solaris2.1x}
+and @samp{CC=gcc -m64}.
+
+@html
+<hr />
+@end html
+@anchor{xtensa-x-elf}
+@heading xtensa*-*-elf
+This target is intended for embedded Xtensa systems using the
+@samp{newlib} C library.  It uses ELF but does not support shared
+objects.  Designed-defined instructions specified via the
+Tensilica Instruction Extension (TIE) language are only supported
+through inline assembly.
+
+The Xtensa configuration information must be specified prior to
+building GCC@.  The @file{include/xtensa-config.h} header
+file contains the configuration information.  If you created your
+own Xtensa configuration with the Xtensa Processor Generator, the
+downloaded files include a customized copy of this header file,
+which you can use to replace the default header file.
+
+@html
+<hr />
+@end html
+@anchor{xtensa-x-linux}
+@heading xtensa*-*-linux*
+This target is for Xtensa systems running GNU/Linux.  It supports ELF
+shared objects and the GNU C library (glibc).  It also generates
+position-independent code (PIC) regardless of whether the
+@option{-fpic} or @option{-fPIC} options are used.  In other
+respects, this target is the same as the
+@uref{#xtensa*-*-elf,,@samp{xtensa*-*-elf}} target.
+
+@html
+<hr />
+@end html
+@anchor{windows}
+@heading Microsoft Windows
+
+@subheading Intel 16-bit versions
+The 16-bit versions of Microsoft Windows, such as Windows 3.1, are not
+supported.
+
+However, the 32-bit port has limited support for Microsoft
+Windows 3.11 in the Win32s environment, as a target only.  See below.
+
+@subheading Intel 32-bit versions
+The 32-bit versions of Windows, including Windows 95, Windows NT, Windows
+XP, and Windows Vista, are supported by several different target
+platforms.  These targets differ in which Windows subsystem they target
+and which C libraries are used.
+
+@itemize
+@item Cygwin @uref{#x-x-cygwin,,*-*-cygwin}: Cygwin provides a user-space
+Linux API emulation layer in the Win32 subsystem.
+@item Interix @uref{#x-x-interix,,*-*-interix}: The Interix subsystem
+provides native support for POSIX.
+@item MinGW @uref{#x-x-mingw32,,*-*-mingw32}: MinGW is a native GCC port for
+the Win32 subsystem that provides a subset of POSIX.
+@item MKS i386-pc-mks: NuTCracker from MKS.  See
+@uref{http://www.mkssoftware.com/} for more information.
+@end itemize
+
+@subheading Intel 64-bit versions
+GCC contains support for x86-64 using the mingw-w64
+runtime library, available from @uref{http://mingw-w64.sourceforge.net/}.
+This library should be used with the target triple x86_64-pc-mingw32.
+
+Presently Windows for Itanium is not supported.
+
+@subheading Windows CE
+Windows CE is supported as a target only on Hitachi
+SuperH (sh-wince-pe), and MIPS (mips-wince-pe).
+
+@subheading Other Windows Platforms
+GCC no longer supports Windows NT on the Alpha or PowerPC.
+
+GCC no longer supports the Windows POSIX subsystem.  However, it does
+support the Interix subsystem.  See above.
+
+Old target names including *-*-winnt and *-*-windowsnt are no longer used.
+
+PW32 (i386-pc-pw32) support was never completed, and the project seems to
+be inactive.  See @uref{http://pw32.sourceforge.net/} for more information.
+
+UWIN support has been removed due to a lack of maintenance.
+
+@html
+<hr />
+@end html
+@anchor{x-x-cygwin}
+@heading *-*-cygwin
+Ports of GCC are included with the
+@uref{http://www.cygwin.com/,,Cygwin environment}.
+
+GCC will build under Cygwin without modification; it does not build
+with Microsoft's C++ compiler and there are no plans to make it do so.
+
+The Cygwin native compiler can be configured to target any 32-bit x86
+cpu architecture desired; the default is i686-pc-cygwin.  It should be
+used with as up-to-date a version of binutils as possible; use either
+the latest official GNU binutils release in the Cygwin distribution,
+or version 2.20 or above if building your own.
+
+@html
+<hr />
+@end html
+@anchor{x-x-interix}
+@heading *-*-interix
+The Interix target is used by OpenNT, Interix, Services For UNIX (SFU),
+and Subsystem for UNIX-based Applications (SUA).  Applications compiled
+with this target run in the Interix subsystem, which is separate from
+the Win32 subsystem.  This target was last known to work in GCC 3.3.
+
+@html
+<hr />
+@end html
+@anchor{x-x-mingw32}
+@heading *-*-mingw32
+GCC will build with and support only MinGW runtime 3.12 and later.
+Earlier versions of headers are incompatible with the new default semantics
+of @code{extern inline} in @code{-std=c99} and @code{-std=gnu99} modes.
+
+@html
+<hr />
+@end html
+@anchor{older}
+@heading Older systems
+GCC contains support files for many older (1980s and early
+1990s) Unix variants.  For the most part, support for these systems
+has not been deliberately removed, but it has not been maintained for
+several years and may suffer from bitrot.
+
+Starting with GCC 3.1, each release has a list of ``obsoleted'' systems.
+Support for these systems is still present in that release, but
+@command{configure} will fail unless the @option{--enable-obsolete}
+option is given.  Unless a maintainer steps forward, support for these
+systems will be removed from the next release of GCC@.
+
+Support for old systems as hosts for GCC can cause problems if the
+workarounds for compiler, library and operating system bugs affect the
+cleanliness or maintainability of the rest of GCC@.  In some cases, to
+bring GCC up on such a system, if still possible with current GCC, may
+require first installing an old version of GCC which did work on that
+system, and using it to compile a more recent GCC, to avoid bugs in the
+vendor compiler.  Old releases of GCC 1 and GCC 2 are available in the
+@file{old-releases} directory on the @uref{../mirrors.html,,GCC mirror
+sites}.  Header bugs may generally be avoided using
+@command{fixincludes}, but bugs or deficiencies in libraries and the
+operating system may still cause problems.
+
+Support for older systems as targets for cross-compilation is less
+problematic than support for them as hosts for GCC; if an enthusiast
+wishes to make such a target work again (including resurrecting any of
+the targets that never worked with GCC 2, starting from the last
+version before they were removed), patches
+@uref{../contribute.html,,following the usual requirements} would be
+likely to be accepted, since they should not affect the support for more
+modern targets.
+
+For some systems, old versions of GNU binutils may also be useful,
+and are available from @file{pub/binutils/old-releases} on
+@uref{http://sourceware.org/mirrors.html,,sourceware.org mirror sites}.
+
+Some of the information on specific systems above relates to
+such older systems, but much of the information
+about GCC on such systems (which may no longer be applicable to
+current GCC) is to be found in the GCC texinfo manual.
+
+@html
+<hr />
+@end html
+@anchor{elf}
+@heading all ELF targets (SVR4, Solaris 2, etc.)
+C++ support is significantly better on ELF targets if you use the
+@uref{./configure.html#with-gnu-ld,,GNU linker}; duplicate copies of
+inlines, vtables and template instantiations will be discarded
+automatically.
+
+
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+
+@c ***Old documentation******************************************************
+@ifset oldhtml
+@include install-old.texi
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+
+@c ***GFDL********************************************************************
+@ifset gfdlhtml
+@include fdl.texi
+@html
+<hr />
+<p>
+@end html
+@ifhtml
+@uref{./index.html,,Return to the GCC Installation page}
+@end ifhtml
+@end ifset
+
+@c ***************************************************************************
+@c Part 6 The End of the Document
+@ifinfo
+@comment node-name,     next,          previous, up
+@node    Concept Index, , GNU Free Documentation License, Top
+@end ifinfo
+
+@ifinfo
+@unnumbered Concept Index
+
+@printindex cp
+
+@contents
+@end ifinfo
+@bye